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Editorial 



By Chris McEwen 



Ah, where to begin? It has been a busy two months since 
the last issue. I have received notes and calls from all over 
complimenting us on the transition. Thank you all. If I owe 
you a letter, please bear with me. It will take a while to put 
everything in its place and calm things down. To add to mat- 
ters, I was recently informed that I have been assigned to a 
project team to revamp the MIS program company wide 
where I work. Nothing like a new job to add to the confu- 
sion! 

There is one thing we seem to lack here at TCJ. There is 
no place for letters from readers. Since I believe the job of the 
editor is that of guiding the audiences' attention from one 
attraction to the next, rather than being an attraction himself, 
there wouldn't be much purpose in a Letters-to-the-Editor col- 
umn. Instead, we will call it Reader-to-Reader. That has a nice 
ring to it and it fairly represents the involvement subscribers 
have in our directions here. Feel free to drop us a line. Mark 
the envelope as "Attention: Reader-to-Reader." 

Practice What You Preach 

When people I know get computers and ask for help, the 
first thing I teach them is that there is nothing more impor- 
tant than backing up your system on a regular basis. I prac- 
tice this regularly on my bbs; every Saturday morning is de- 
voted to a ritual of backing up the message system. The lack 
of a good CP/M backup system keeps me from doing the 
whole machine every week. Or should I say, what I thought 
was a lack of a good system. In calling around the country, I 
found that Roger Warren, sysop of Z-Node 9 in San Diego, 
not only has devised a scheme but he has gone so far as to 
modify the BIOS of his Ampro to speed the task by relocating 
the directory tracks to the center of the floppy disk! Now, 
that is getting serious. We will be hearing from Roger on this 
scheme in the near future. 

There is a more immediate reason I bring this topic up. I 
found myself sitting at a dead MS-DOS machine the other 
week. The beast (I call her Amanda at better moments) had 
held all the files for this issue just moments before. And then, 
right at deadline, she decided to blow her file allocation 
tables. From all we can put together, she took a power surge. 
No problem for a fellow who preaches regular backups, 
right? Uh, right. Well, this preacher is out looking for a tape 
drive. This will happen just once. 

The irony of this is that our lead article this issue regards 
power protection. This is timely, with the spring thunder 
storms coming along. Wendell Laidley questions whether to- 
day's devices might not divert the surge to the delicate data 
lines through ground. Interesting. Were this to have hap- 
pened, I would not have lost the FAT, I would have lost the 
machine! Continuing on, he tells us that MOVs break down 
in service but fail to give warning. Very nice. The surge pro- 



tector I have Amanda hooked up to is ten years old. It was 
the finest I could buy back then, and I certainly didn't see the 
need to throw it out. Perhaps I should think again. 

By the way, I asked one of the major manufacturers of 
powerline protection devices if they would want to submit 
something to counter Wendell's position. They declined. 
Since this is an important topic, I open the door to other 
perspectives. 

Gotta Get a Fix! 

Had some correspondence asking where one can go to get 
CP/M gear fixed. This is becoming more of a problem. The 
systems we use are getting up in years and there seems to be 
fewer people who know their way around them. If you are 
involved in repair of such equipment, let us know. But there 
are bright spots as well. As you know. Advent stopped sell- 
ing the TurboROM a while back. That was a crushing blow- 
there is no single improvement a Kaypro owner can make 
more important than putting in this ROM. Then, out of the 
blue, a message was passed around the Z-Nodes. Seems 
Chuck Stafford has obtained the rights to the ROM and has it 
back in production. Better yet, the price has dropped to $35. 
You can call Chuck at his home. The number is (916) 483- 
0312. Or drop him a line at 4000 Norris Avenue, Sacramento, 
CA 95821. 

We're Ail Connected 

Big news! A couple of special places have been established 
on GEnie for TCJ readers. One, in the Forth SIG (page 710), 
seems to have been there for a couple of years. It was put up 
by readers. Art didn't know it was there! I discovered it by 
accident one afternoon while exploring the system. And the 
CP/M sysop. Bill Juliani, has established a TCJ SIG in his 
area. This is category 15 on page 685. I am moderating and 
you are cordially invited. I promise that I will make regular 
visits to the Forth area as well. Meanwhile, if you are not a 
GEnie subscriber, you might want to look at their advertise- 
ment on the inside front cover. I printed out their index of 
services in fine print one afternoon and it took some six 
pages. More to the point, both the Forth Interest Group (FIG) 
and the most active CP/M group of all the major services live 
on this system. 

Speaking of being all connected, we can look forward to 
several articles in future issues on Fido-Net and usenet. Mark 
Burrow of Houston, Texas, promises to talk about a new bbs 
system for CP/M written in Modula-2 that interfaces quite 
nicely with Fido-Net. And Andy Meyer of Dunellen, New 
Jersey was a beta tester for David Goodenough's uucp sys- 
tem. He will tell us of the CP/M usenet tools. With luck, we 
will see one or both in the next issue. 

continued page 40 
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Computer Network Power Protection 

Problems, Myths and Solutions 



By Wendell H. Laldley 



[Editor's Note: The following paper was presented to the Power Quality conference in October, 1990 and is reprinted here with permission 
of the author. The points raised in this paper regarding power protection are of importance to everyone using computer equipment. Your 
computer investment is more than simply money: systems under development may be irreplaceable and lost data could mean a lost 
business or job. Wendell's position runs counter to prevailing practice. If he is right, the computer using public is at risk. While he 
specifically addresses networked sites, the weaknesses he cites would could apply equally to any micro computer system with external 
peripherals. TCJwill offer space for viewpoints from others on this vital topic] 



Introduction 

Modem computer networks are uniquely vulnerable to 
powerline disturbances because they bring together the high 
energy powerline and sensitive low energy digital integrated 
circuits. Ordinary surge protection techniques can actually 
harm computer networks by diverting dangerous surges into 
delicate network datalines, through the common reference 
ground. Because of this, computer networks need special at- 
tention in powerline surge protection. 

Point-of-Use Surge Protection 

First generation surge protection strategies followed the 
conventional wisdom of shunting unwanted surge energy to 
ground, the ultimate surge sink. The most common practice 
was to build voltage sensitive shunt components into exten- 
sion cord power strips, usually using inexpensive MOVs 
(metal oxide varistors), or sometimes other shunt compo- 
nents such as avalanche diodes (also called TranZorbs), ca- 
pacitors or even gas tubes. 

The components were originally wired only between the 
line and neutral conductors. Unfortunately, this strategy cre- 
ated a large common mode surge with a risk of arc-over 
between neutral and ground, so most surge suppresser mak- 
ers began connecting shunt components between all three 
powerline conductors, line and neutral and ground, calling 
this configuration "all three modes of protection". 

For simple stand-alone electronic equipment this strategy 
provided basic protection, particularly if the user understood 
the limitations of the components, such as the characteristics 
of MOVs to deteriorate with each surge incident, and of ava- 
lanche diodes to fail "open" in the face of a moderate to 
severe surge, thus exposing the protected load to the full 
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surge. This "three mode" method of surge protection was 
based on the premise that if voltage differences between the 
powerline legs at the sensitive electronic load were kept 
down to acceptable levels, then it would not matter if all 
three conductors were allowed to "float up" with respect to 
some absolute or constemt reference such as earth ground. In 
this way the protected equipment would be like a raft with- 
out an anchor floating on water— when a wave came along, 
the whole raft would float up, but so long as there were no 
anchor to prevent the raft rising, it could float up and down 
harmlessly. The theory was that if the surge energy or volt- 
age was spread evenly among all three powerline conduc- 
tors, its effect would be neutralized, since equipment damage 
should only occur if potential differences arose, and by inter- 
connecting all three lines with shunt components, such dif- 
ferences would be precluded. 

The advent of computer networks changed all this by in- 
validating this fundamental assumption, much as a fixed 
length anchor line would invalidate the assumption of the 
free-floating raft in a rising tide. The difference between 
stand-alone and interconnected computers around from the 
fact that dataline signals between devices are referenced to 
ground, and the only "ground" available at the point of use 
of the sender or receiver is the powerline safety ground con- 
ductor, represented by the round pin on conventional 110 
volt receptacles. 



Problems 

Now the practice of shunting surges to the powerline 
ground becomes unacceptable, because shunting a surge to 
the powerline ground will cause the ground conductor volt- 
age to rise. This happens because the inductance of the 
ground conductor between the recep- 
tacle and the actual zero impedance 
ground at the building service entrance 
will present impedance to the propaga- 
tion of the high frequency surge, caus- 
ing the voltage on the ground conduc- 
tor at the receptacle to rise with respect 
to true ground at the building service 
entrance. This is shown in Figure 1, 
where the voltage gradient along the 
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powerline conductors is shown. In effect, a voltage divider 
operates, and where the three powerline conductors are of 
equal length, Figure 1 shows the voltage distribution that will 
occur. 

Since the powerline ground conductor is the only ground 
available for reference by the signal dataline, diverting surges 
to it will have the effect of diverting powerline surges di- 
rectly into the datalines, and thus into the sensitive low volt- 
age internal circuitry of the computer'. 



may alter data in bit streams passing through the CPU. The 
huge costs of computer network failures were reported in 
1989 by Infonetics, a California market research firm.^ They 
they reported that local area network downtime costs the 
average Fortune 500 company $3.48 million annually with 
the average respondent reporting 23.6 network failures annu- 
ally, of 4.9 hours average duration. Clearly, these costs de- 
serve attention, and one cause of network failure is power- 
line surges. 
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Ground: Surge Sink, or Voltage Reference 
One, But Not Both 

Given this problem, the powerline ground conductor 
should not be used as a surge sink with interconnected com- 
puters where it is needed for voltage reference by datalines. 
The damage caused by diverting surges to ground in net- 
worked electronics was first reported by Francois Martzloff 
in the 1988 IEEE paper "Coupling Propagation and Side Ef- 
fects of Surges in an Industrial Building".^ Martzloff's re- 
search team was performing surge tests on an office building 
over a weekend, and when the office workers returned Mon- 
day morning they found their printers did not work and the 
printer data ports had been damaged. Initially, the research 
team had not expected that surges they had applied only to 
the powerline would have damaged datalines. On reflection, 
they recognized that the powerline surges had indeed been 
diverted by shunt surge protectors into the printer datalines 
through the common reference ground. 

Prdjlems caused by the interaction of the powerline and 
datalines through the common ground include physical 
hardware damage as reported above, and disruption in the 
form of program lock-ups, data alteration, parity errors and 
transmission failures. High frequency surges, sometimes 
with considerable energy, couple into digital circuitry and 



Myths of Surge Protection 

Because transient analysis is one 
of the more complex and less gen- 
erally understood branches of elec- 
trical engineering, the field of surge 
protection has developed a number 
of myths over time. Here are some 
of them, with possible explanations 
of their origins. 



Myth 1 : "Any Surge Protection 
Is Better Than No Surge 
Protection." 

This is perhaps the most reason- 
able yet the most misleading of all. 
As explained above, it is shunt 
surge suppressers themselves 
which divert powerline surges into 
datalines, so with networked com- 
puters, the wrong design surge 
suppresser can actually cause com- 
puter network failures. With no 
surge protectors at all, incoming 
surges will encounter the com- 
puter's power supply, which is 
considerable more surge tolerant 
than the dataline circuitry. So net- 
work users may actually be better 
off with no surge suppresser than 

they are with shunt design suppressers which divert surges 

into datalines and modems.* 

Myth 2: "UPSes Provide Dependable Surge 
Protection." 

Because a UPS costs far more than a surge protector, it is 
commonly assumed to provide premium surge protection. 
Essentially all micro-computer UPSes, lOOOvA and under, are 
a combination of an inexpensive MOV surge suppresser and 
a battery back-up power source. The MOV surge protection 
is designed to protect the UPS circuitry, and diverts incoming 
surges to ground like a common surge protector (see Figure 
1). Once on ground, the surge will circumvent the UPS and 
couple directly into any computer datalines.^ Since many mi- 
cro-computer UPSes are used in the context of local area 
networks, this problem must be solved or the UPS will con- 
taminate the network datalines. Some UPS makers show how 
surges which encounter the battery of the UPS are effectively 
eliminated. This is true for the surges which reach the bat- 
tery, but most are diverted away from the UPS circuitry to 
ground before they reach the battery. Thus the belief that the 
battery in a UPS is an effective surge sink is not entirely 
relevant or dependable. Just like the basic surge suppresser, 
the UPS protects the computer power supply, but in doing 
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so, it endangers the datalines. 

Another risk exposure with UPSes is the alternative power 
path around the battery and inverter. So called standby UP- 
Ses normally provide direct utility power to the computer, 
with only the MOVs at the UPS power inlet as surge protec- 
tion, while on-line UPSes generally have a bypass circuit to 
enable utility power to flow directly to the load in the event 
of UPS failure. Both these circuits provide paths to the pro- 
tected load for incoming surges. In the case of the standby 
UPS, the path is direct, while for the on-line UPS, the surge 
must pass through the transfer switch, but these switches are 
often solid state components with modest tolerance for high 
energy surges, so they may not prevent a moderate to sever 
surge from passing through them to the protected load. 

Myth 3: "Transformers Are The Best Surge 
Protectors." 

Transformers are designed to transmit power, not to sup- 
press it. The primary source of surge protection in a trans- 
former is its leakage inductance, which relates to its mass. 
This inductance provides some 
surge protection, but less than 
would inductors specifically 
designed for surge suppres- 
sion. A transformer is far from 
an ideal surge suppresser and 
presents significant disadvan- 
tages such as ringing, regula- 
tion, increased source imped- 
ance and efficiency loss. They 
also have substantial parasitic 
capacitance to ground which 
can couple surges to ground,' 
and transformers used for 
surge protection sometimes 
use MOVs since the trans- 
former may be unable to 
handle the large voltages in ex- 
ternal surges. 

The two major advantages 
of transformers are that they 
have surge absorbing mass 
(leakage inductance) and are 

available as a complete sub-assembly which eliminates the 
need to design a custom surge processing circuit. The often 
cited benefit of common mode protection with isolation 
transformers is somewhat of a red herring issue with com- 
puters, as discussed below under Common Mode. Also, 
while point-of-use isolation transformers re-establish the 
neutral-ground bond on the transformer secondary, the new 
ground is rarely connected to a new earth rod, and is almost 
always connected to the incoming powerline green wire, po- 
tentially compromising surge isolation, at least in respect to 
dataline exposure through the reference ground. 

Myth 4: "Voltage Regulating Transformers Are Useful 
With Computers." 

Most modem desktop computers use switch mode power 
supplies rather than the older style linear power supplies. A 
switch mode power supply draws from the powerline ac- 
cording to the amount of energy it requires to maintain its 
output power. In this sense it is a natural integrator of volt- 
age and current, and it compensates naturally and spontane- 



ously for voltage fluctuations. If the voltage drops, it draws 
current for a longer period, until it replenishes the energy it 
has put out since its last recharging from the previous cycle 
of the power wave (see Figure 2). Because of this natural 
ability of a switch-mode power supply to accommodate 
varying source voltages, it gains no benefit from a voltage 
regulating transformer. Instead, the increased impedance in- 
serted into the line by the transformer may hinder the power 
supply by restricting the current available to the power sup- 
ply when it calls for current. Switch mode power supplies 
prefer a low impedance power source that can deliver high 
current when demanded. Inserting a tap-switching voltage 
regulating transformer in the powerline will add impedance 
and restrict the amount of current available to the computer 
power supply. It may also introduce noise if the tap switch 
hunts back and forth between adjacent output taps. Com- 
puter switch mode power supplies often have a wider toler- 
ance for input voltage than do regulating transformers them- 
selves. Thus the primary benefit of a voltage regulating trans- 
former is its leakage inductance, which is much less than in 




Area Under Curve Si for 



Time Ti = Area Under Curve S2 for Time Ti 
FIGURE 2: Switch Mode Power Supply 



isolation transformers, but the regulator introduces offsetting 
disadvantages, and its voltage regulation offers no material 
benefits. 

Myth 5: "Common Mode Surges Cause Computer 
Problems." 

Just as modem switch mode power supplies compensate 
spontaneously for voltage variations, they also naturally at- 
tenuate common mode noise. Desktop computer switching 
power supplies have five orders of magnitude of common 
mode noise attenuation built in. The EMI / RFI filter pro- 
vides two orders of magnitude attenuation, and the high fre- 
quency isolation transformer in a switching power supply 
offers three more orders of magnitude common mode pro- 
tection at surge frequencies. Common mode sensitivity in 
computers is a function of slew rate and amplitude of the 
common mode disturbance. Low voltage, low frequency 
ground potential differences will not cause disruption or 
damage, because the primary cause of disruption is coupling, 
which depends on frequency and amplitude. 
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Computers are inherently immune to common mode dis- 
turbances below a certain threshold, but problems occur 
when high energy incoming normal mode surges are con- 
verted to common mode surges by the action of a shunt 
surge suppresser. The only source of external surges is nor- 
mal mode since neutral and safety ground are grounded to- 
gether at the service entrance (see Figure 1). The high energy 
of external surges converted to common mode may exceed 
the common mode tolerance of the computer, but naturally 
occurring high frequency, low energy common mode noise 
will not. This problem can be eliminated by keeping shunt 
surge suppressers off circuits powering computers, thus 
eliminating the conversion from normal mode to common 
mode. 

Myth 6: "Computer Modem Damage Is Cause By 
Surges On The Phone Line." 

The telephone line is a high impedance circuit which can- 
not support high energy surges, so they rapidly die away 
after the inducing source (i.e. lightning) disappears. In con- 
trast, the low impedance powerline provides an ideal propa- 
gation network for high energy surges. Also, the telephone 
line service entrance is protected to under 300 volts, which 
powerline surges can reach 6,000 volts before they will arc 
over in 110 fixtures. 

The mechanism for most computer modem damage is 
through high energy powerline surges being diverted to the 
reference ground and coupling into the digital side of the 
modem. The elevated voltage then seeks the telephone line 
ground reference on the analog side of the modem and arcs 
through the modem.'' 

As a corollary to this, it can be seen that dataline or tele- 
phone line protectors may not be effective or may even cause 
disturbance problems. Dataline protectors which limit volt- 
age between conductors are of limited benefit since exter- 
nally induced surges, such as from lightning, will appear 
commonly on both (or all) conductors passing the the induc- 
ing magnetic field, and the problem is not between individ- 
ual conductors, but between the conductors and ground. 
Similarly, telephone line protectors which provide shunts to 
the powerline ground, commonly found as cube taps which 
provide two telephone line jacks and plug into 110 volt re- 
ceptacles (with plastic rectangular inserts and a conductive 
ground pin insert to the receptacle) may introduce more dis- 
turbance to the telephone line from the powerline ground 
than they relieve from the telephone line to the powerline 
ground. 

Myth 7: "Signal Ground Is Isolated From Chassis 
Ground." 

Some manufacturers attempt to isolate signal ground 
from frame ground, but all such isolation configurations 
have coupling coefficients and dynamic ranges, both of 
which are likely to be exceeded by high energy external 
surges. An inspection of most such isolation circuits shows 
their effectiveness to be generally limited to short duration, 
low energy noise. 

Myth 8: "Transformer Coupled Datalines Are Immune." 

These configurations also have coupling coefficients and 
dynamic ranges, and their effectiveness against low energy 
noise may not extend to much higher energy surges diverted 
to the powerline reference ground by ordinary shunt surge 



suppressers. Even optical dataline converters may be dis- 
turbed by such high energy surges. 

Myth 9: "The Only Risk From The Powerline Is 
Hardware Damage." 

Computers are vulnerable to data alterations as bit 
streams pass through microprocessors, and stray power 
surges can alter data or programs, causing data errors that 
may never be found or program errors or lock-ups which 
cannot be traced. The consequential cost of such soft damage 
can be very high.^ 

Myth 10: "My Surge Protector Is A Permanent Device." 

Most point-of-use surge protectors use metal oxide varis- 
tors (MOVs) as their primary protection component. This in- 
expensive (15 cent) component, despite all its strengths, 
wears out a little with each surge* above a very modest 
threshold that is exceeded many times daily in most environ- 
ments. As Mark McGranaghan wrote in the premier issue of 
Power Quality, "MOVs cannot handle the energy generated 
by the switching of utility capacitor banks."' Unfortunately, 
the race among surge protector manufacturers to provide the 
best protection (lowest let-through voltage) has led them to 
use lower voltage MOVs which age faster and fail sooner.'" 
The normal failure mode for an MOV is thermal runaway to 
short circuit, and they have been known to cause fire." [Ed.: 
Consider this as you look at ttie MOV suppresser sitting on your carpet 
under your drapes.) MOV based surge suppressers wear out 
and should be replaced periodically. Unfortunately, the 
equipment to test an MOV is very expensive (on the order of 
$20,000) and indicator lights purporting to show that protec- 
tion is operational are not always reliable, and are sometimes 
wired across the powerline, indicating only that the power- 
line is live. 

Myth 11: "Nothing Can Stop Lightning." 

Of course, this simple statement is true, but in all but the 
rarest of cases, it may be misleading. Two important qualifi- 
ers operate to limit damage from lightning. The first is that a 
direct lightning strike is extremely rare, and, of course, in 
that case, equipment and personnel may both be destroyed. 
But lightning normally manifests itself in the powerline as 
induced currents caused by the lightning magnetic field on 
the conductors passing through the field. Thus we normally 
need only deal with the induced surge, not the lightning 
strike itself, and the induced surge energy will be limited by 
the capacity of the conductor to carry the surge energy. The 
second factor is that surge voltages are limited to 6,000 volts 
by the arc-over level of fixtures in 110 volt circuits. Thus 
surge protection need only deal with voltages up to 6,000 
volts, and currents determined by the impedance of the 
source. There are surge protectors available which suppress 
up to 6,000 volts and unlimited currents to under 250 volts 
without degradation, without disturbing the critical reference 
ground. 

Myth 12: "You Get What You Pay For." 

The assumption that higher priced surge protectors pro- 
vide greater effectiveness and reliability is not always valid. 
Almost all surge suppressers under $200 rely on the same 
fundamental MOV components. Much of the supplementary 
circuitry is peripheral to the surge protection, such as lights 

continued page 39 
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Floppy Disk Alignment with the RTXEB and Forth 

Part One 

By Frank C. Sergeant 



Introduction 
General Description 

This paper describes a Floppy Disk Drive Aligner built 
around the RTX2001A microprocessor. It shows how to add 
I/O ports and control hardware to generate and measure 
voltages anu time intervals. Examples show how to control 
the RTX's interrupts and timers and how to put all these 
parts together to create a smart instrument that provides sev- 
eral improvements over the usual method of aligning drives. 
A full source code listing and schematic are included. These 
hardware and software techniques can be applied to almost 
any RTX project. 

A disk exerciser controls which head is active and steps it 
from track to track. The oscilloscope displays the signal from 
the drive's read amplifier. These are used with an analog 
alignment disk (AAD) that contains special patterns needed 
to align the drive. The Aligner uses a standard AAD and 
replaces the exerciser and the oscilloscope that are normally 
used. It could display the results on a self-contained LCD or 
through a serial line to a PC or terminal. 

The RTX2001A provides advantages both during the de- 
sign stage and in the final product. An RTXEB Evaluation 
Board with Forth in ROM and a wire-wrap area was used, 
with an XT clone, as the entire development environment. 
This could well obsolete expensive development stations. 
Development was easy because of the interactive access to 
the hardware and the modular nature of Forth. The RTX is 
fast, letting software replace hardware (in this application, 
for example, the ADC and the Peak Detector were done in 
software). 

Alignment 

An alignment is done to restore the correct mechanical 
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relationship between the head and the diskette. When a head 
moves out of alignment the drive may not be able to read 
disks it wrote some time ago or to exchange disks with other 
drives. There are two basic head position adjustments: RA- 
DIAL (when on track 16, the head should be the correct dis- 
tance from the center of the disk) and AZIMUTH (the head 
should be "square" to the track, rather than skewed). At the 
same time such things as motor speed and the various sen- 
sors are checked and adjusted. 

The discussion will center around the alignment of a Tan- 
don 5-1/4 inch, 360K drive using the DYMEK DK 502-1 
AAD. Generally the same procedure is used for all floppy 
drives, but a different alignment diskette will be needed for 
other densities. 

Aligning Disk Drives 
The Problem 

Ordinarily, a drive is aligned using a disk drive exerciser 
and an oscilloscope. The bulkiness of this equipment makes' 
aligning drives at the user's site awkward, so drives are usu- 
ally removed and taken to the shop for servicing. This in- 
creases the turn-around time and the expense and inconven- 
ience to the user. 

One approach to this problem is the digital alignment 
diskette. This eliminates the need for the oscilloscope and the 
exerciser. The idea is to run a program on the computer 
whose drive is being aligned. This eliminates the bulky 
equipment but makes the technician's work more difficult 
since the drive must stay attached to its computer. Often 
there is not proper working room and the drive balances 
precariously on top of the open computer case. In additipn, 
technicians generally believe that a digital alignment diskette 
produces inferior results. Often, it is merely used as a quick 

Go/ No Go test to decide whether to 

take the drive to the shop for an (ana- 
log) alignment. 



The Solution 

The RTX2001A runs fast enough 
that it can combine the disk drive exer- 
ciser functions and the oscilloscope 
function into a single compact unit. 
Npw, accurate on-site alignment can 
be done (using the AAD) and this be- 
comes the preferred choice. The RTX 
chip with some simple support cir- 
cuitry, on perhaps a 4 x 5 inch board. 
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( Adjust the RTX mamory map to give the moat code apace ) 



17186 DUP H-FENCE I H 1 



17194 R-TOP 1 



Lower the start of the dictionary) 
to just above the end of the data) 
space needed by the Aligner) 

Mark the new top of data space . ) 
When we finish loading, THERE ) 
will have a value of 17184, which) 
is just under our new value for) 
H-FENCE and H. R-TOP must be set) 
higher, though, or EBFORTH thinks) 
we've crossed the limit when we) 
really haven't. 



•cr f 3901 

The memory map of EBFORTH separates data space from 
code space { for easy ROHability) . During development 
these are both in RAM, which can be allocated between 
them by changing a few pointers. 
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( ' Terminal specific definitions ) 

I 2EMIT ( hhll -) DUP -8 SHIFT ( xxll xxhh) EMIT EMIT ; 

: LOAD ( scr# -) 

DECIMAL 5 ( ie code to request a screen) EMIT 2EMIT ; 

: THRU ( 1st last -) 

DECIMAL 6 ( ie code to request a range of screens) EMIT 
SWAP ( last 1st) 2EMIT 2EMIT ; 

: AT ( y X -) 

8 ( ie code to request direct cursor positioning) EMIT 

SWAP ( X y) EMIT EMIT ; 
: CLS ( -) 9 ( ie code to request clear screen) EMIT ; 



scr f 3902 

2aiIT Break a 16 bit number into 2 bytes and EMIT 
them. 

LOAD Request that host send a screen. 

THRU Request that host send a range of screens. 

AT Ask host to position cursor at y x co- 
ordinates. Origin is upper left corner. Height 
is sent lat followed by width. 

CLS Request that host clear the screen. 
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( Variables ) 

VARIABLE OUT ( 

VARIABLE TRK ( 

VARIABLE HEART ( 

VARIABLE Vb ( 

VARIABLE COMP-FLAG ( 

VARIABLE #PEAKS ( 

VARIABLE OSCALE ( 

VARIABLE OTRIG ( 
VARIABLE WINDOWS 
14 ALLOT ( starting 



holds last value written to output port) 
holds current disk drive track position) 
holds address of active test routine) 
holds base voltage for azimuth test ) 
set true if coriparator goes high) 
EI3-INTW uses it to count wave-form peaks) 
''oscilloscope'' scaling factor for raw data) 
' ' oscilloscope ' ' trigger delay in ms ) 

and ending times for azimuth bursts) 



8 OSCALE 1 
25 OTRIG 1 



( reasonable starting value for cat's eye display) 
( ms from index pulse ) 
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OUT Holds last value written to the output port. 
This is important because the output port is 
write-only. We cannot read it back, so every time we 
write a new value to it, we save a copy in the variable 
OUT. 

TWC Holds current disk drive track. The only time 
we can read the track position directly fron the drive 
is when it is on track zero (the trackO line goes 
true). The word RESET steps the head outward, toward 
track zero until the trackO line goes true and then 
stores a zero in TRK. Thereafter every time we step the 
head we also update TRK. 

NINDOHB This array holds the starting and ending timer 
values for each of the four azimuth bursts. This 
information is discovered by CLOCK and MARK and then 
used by AZ to measure the azimuth burst amplitudes at 
the correct times. 
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( Constants ) 

199 CONSTANT #SAMPLES 

( # of sauries less one to be collected for cat's eye 

( bit-masks for output port devices ) 



( 1 CONSTANT LED 
( 2 CONSTANT ♦DRVO 
( 4 CONSTANT *MOTOR 
8 CONSTANT HEAD 
16 CONSTANT 'DIR 
32 CONSTANT 'STEP 
( 64 CONSTANT *WE 



( 128 CONSTANT *WRITE ) 



•cr I 3904 

iSAMPLBS Number of measur<iments to take (less one, to 
adjust for FOR NEXT) for the cat's eye pattern during 
one revolution of the disk. 

The only output lines we need (connected to the 34 pin 
disk connector) are HEAD, 'DIR, & *STEP. The 'WE, 
•WRITE, & LED bits are connected, but ccnimented out 
here since we don't use them. The 'DRVO and ♦MOTOR 
lines are not connected to the output port. Instead, 
they are hardwired active (low). If you wanted to put 
them under program control, they could be connected to 
bits and 1 (with bit masks of 2 and 4). 

These control lines are connected to the lower byte of 
the output port. The DAC is connected to the upper 
byte. 
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replaces essentially all of the hardware of both the disk exer- 
ciser and the oscilloscope! 

The technician communicates with the Aligner through 
any terminal or PC, perhaps the PC whose drive he is align- 
ing. Or, the Aligner could show its results on an LCD. By 
reducing bulk and eliminating complexity and extra cables, 
the RTX makes on-site alignment more convenient, cutting 
servicing costs and downtime. Since it is software based, up- 
grading to handle new types of drives is easy. 

How The Exerciser Part Works 

The standard 34 conductor cable carries the write-protect, 
track-zero, index, and read-data signals from the drive to the 
Aligner and the step, direction, and head select signals from 
the Aligner to the drive. The Aligner controls the step line to 
move (SEEK) the head from track to track, and monitors the 
track-zero switch. With this and the simple terminal interface 
it can step the drive to the proper tracks to read the AAD's 
different test patterns and report the status of the drive. To 
check the motor speed, the time between index pulses is 
measured. To check the track-zero switch, the track-zero line 
is monitored while the head is stepped toward track zero. 

How The Oscilloscope Part Works 

The Aligner measures the amplitude of the read signal by 
doing zmalog to digital conversion in software, using the 
D AC 2ind comparator. These readings are then displayed as a 
histogram using columns of 'X's on a character based termi- 
nal, or as a higher resolution picture on a graphics terminal. 
This provides the cat's eye and azimuth burst displays the 
technician needs. 

Interfacing to the RTX 
I/O Port Hardware 

Although the ASIC bus has some interesting possibilities 
for on-chip integration, for our purposes just think of it as the 
I/O bus. This is also called the G-bus. It is made up of 16 
data lines, 3 address lines, and 2 control signals. The 3 ad- 
dress lines mean that you can have a maximum of 8 I/O 
addresses. Each I/O address can access 16 inputs and 16 
outputs, for a total of 32 bits per address. 

Since the Aligner only needs 4 inputs and 14 outputs (and 
we could get by with fewer) we don't need to decode the G- 
bus address lines at all, only the control signals are needed. 
GIO* goes true (low) on either a read or write of a G-bus 
address. GR/W* goes low for a write and stays high other- 
wise. We latch data to the output port only when both GIO* 
and GR/W* are low. We enable data from the input port 
only when GIO* is low and GR/W* is high. Because of this 
approach any external G-bus address will work with our 
ports. Throughout the listing G-bus address 31 is used, but 
any of the addresses 24 through 31 will work equally well. Be 
careful not to use addresses through 23 as they address 
internal devices on the ASIC bus (that is, they address proc- 
essor registers). 74HC373 latches are used for all the ports. 
Two of them face outward, providing 16 outputs. One faces 
inward, providing 8 inputs. Note, with this method the out- 
puts are write-only. If you try to read them, you will get the 
inputs at the same address. 



I/O Port Software 

31 G@ reads the input port and leaves it on the stack, u 31 
G! stores the number u to the output ports. Only 8 bits of the 
16 that are available jire connected for the input port. All 16 
bits are connected for the output port. Usually we will not 
just store a number to the output port; we will also save a 
copy in the variable OUT. This keeps track of what we last 
wrote, allowing us to change selected bits without disturbing 
the others. 

Here is an example of how to use the I/O ports. Look at 
the schematic and note that the least significant bit (LSBit) of 
the output port is connected through an inverter to an LED. 
(The base is hexadecimal for these examples.) The simplest 
way to flash the LED is to type 



HEX 




31 Gl 


( turn on LED) 


31 Gl 


( turn off LED) 


31 Gl 


( turn on LED) 


31 Gl 


( turn off LED) 



over and over. If the LED goes on and off, the output port 
address decoding (and our understanding of it) is verified. 
The above approach has the flaw that we might be altering 
other bits (that affect devices other than the LED). We can't 
just do 



31 Gt 
1 Gt 



1 OR 

PFFE AND 



31 Gl 
31 Gl 



because we would not be reading the output port. We would 
be reading the input port. So, we save a copy every time we 
store something to the output port, and we read this copy 
when we want to know what we last wrote. This would 
work: 



VARIABLE OUT 
FFFF DUP 31 Gl 

OUT i 1 OR 

OUT t FFFK AND 

OUT « 1 OR 

OUT i FFFE AND 



( define a variable to keep the copy) 
OUT 1 ( put bits in a known state ) 



DUP 31 Gl 

DUP 31 Gl 

DUP 31 Gl 

DUP 31 Gl 



OUT 1 ( LED on) 

OUT 1 ( LED off) 

OUT 1 ( LED on) 

OUT 1 { LED off) 



Naturally, using Forth, we won't keep doing all this typ- 
ing. Instead we will hide these details in a convenient defini- 
tion, as follows: 



ON ( bit-mask -) 
OFF ( bit-mask -) 



OUT t OR 
NOT OUT i AND 



DUP OUT 1 
DUP OUT I 



31 Gl 
31 Gl 



Since the LED is connected to the LSBit of the port, the bit- 
mask for it is simply 1. Note that OFF takes care of inverting 
it for the AND so that we don't have to think in comple- 
ments. Now we can flash the LED with 



1 ON 
1 OFF 
1 ON 
1 OFF 



but, why should we have to remember that the bit-mask for 
the LED is 1 ("because it is easy to type" you might reply)? 
We'll hide that detail too: 



1 CONSTANT LED 
LED ON 
LED OFF 
LED ON 
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( r«ad disk a'tatus frcm input poirt ) 

: PJ ( - u) 31 G8 ; MACRO ( ' 'P fetch'' read from input port) 

: INX7 ( - f ) P« 1 ( ie bit mask for index line) AND 0= ; 

I 7H0T-INX ( -) BEGIN INX7 0= UNTIL ; 

: VINX ( -) BEGIN INX7 UNTIL ; 

: SYNC ( -) 7N0T-INX 7INX ; ( wait for start of index pulse) 

! TKK07 ( - f ) P8 2 ( ie bit mask for trk 0) AND 0= ; 

; WP7 ( - f ) P8 4 ( ie bit mask for write protect) AND 0= ; 



ser f 360« 

( write to output port ) 

: PI ( u -) 31 Gl ; MACRO ( "P store" write to output port) 



( set or clear a specific bit without disturbing the others) 



: ON ( bit-mask -) OUT t OR DUP OUT 1 PI ; 
: OFF ( bit-mask -) NOT OUT t AND DUP OUT 1 PI ; 



-1 ON 
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iUad Disk Status - The input and output porta aiv 
separate ports accessed by a reeul or write of ASIC 
address 31. The GR/W line determines whether the 16 
input bits or the 16 output bits will be accessed. As 
long as we don't need more than 16 'I's and 16 'O's, we 
can have 32 I/O lines without decoding the ASIC address 
lines . 

To read a status line, we read all 16 bits and then 
isolate the one we are interested in by ANDing with its 
bit-mask. Since these are active low, we follow with 
0= so we will have a true flag only if the line we are 
interested in is low. 
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PI Write the value on the stack to the output port. 

ON This reads the variable OUT to find out what we 
wrote to the output port last time, ORs in the new bits 
we want to turn on, saves the result in OUT for use 
next time, and writes the result to the output port. As 
soon as ON is defined, we use it to write all ones to 
the output port so it will be in a known state. The 
point is that ON let's us turn specific bits on without 
disturbing the state of the other bits. 

OFF Does the same thing except it turns specific bits 
off without disturbing the others. 
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( select active disk head - either head zero or one ) 

! HO ( -) HEAD OFF ; 

: HI ( -) HEAD ON ; 

t -H ( -) ( "toggle head") 

OUT t HEAD AND IF HO EXIT THEN HI ; 
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BO Make head zero the active head. 



Bl Make head one the active head. 

-B Switch from one head to the other. 
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( step head to selected track ) 

: STEP ( -) *STEP OFF 5 MS *STEP ON 10 MS ; 

I +STEP ( -) ♦DIR OFF STEP 1 TRK +1 ; ( move hesui inward ) 

: -STEP ( -) 'DIR ON STEP -1 TRK +1 ; { move head outward ) 

: SEEK ( track -) 

DUP TRK t - ( trk #steps) 

*DIR OVER 0< IF ON ELSE OFF THEN ( trk #steps) 

7DUP IF ABS 1- FOR ( trk) STEP NEXT THEN TRK 1 ; 

I RESET ( -) BEGIN TRK07 0= WHILE -STEP REPEAT TRK I 

: TSaHl ( -) 1 SEEK ; 
I TRK16 ( -) 16 SEEK ; 
: TRK34 ( -) 34 SEEK ; 
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Whenever the *STEP line is pulsed low, the heads move 
one track either in or out. The *DIR line determines 
the direction. When *DIR is low, when *STEP is pulsed, 
the head will be stepped outward (toward lower 
numbers). Otherwise, when *STEP is pulsed, the head 
will move inward (toward higher numbers). 



Move the head to the specified track. It 
compares where it is (based on the current value of 
TRK) to where you want it to go, to determine which 
direction and how many STEPS. All these words that 
affect the track location must update TRK. Before 
stepping the heads the 1st time, RESET should be 
performed to synchronize the head location with TRK. 
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( Clamp value between allowable limits ) 

: CLAMP ( n lower-limit upper-limit - n') 
>R MAX K> MIN ; 



•cr i 
CLAMP 



3909 

Force the number to be in bounds. 
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( accept a number frcm keyboard) 

: #IN ( - u) 

PAD 1+ 5 EXPECT PAD CONVERT 2DR0P ; 



•cr f 3910 

IIM Accept up to 5 keystrokes and convert to a 
number. This word allows the menu to prompt the 
technician for a number. This is used in the words 
onilG and OSCALB to get the now values for the cat's 
eye trigger delay and the scaling factor (Rjuige) for 
the cat's eye graph. 



10 
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Now, if we connect another device to the next bit over, it 
would have a bit-mask of 2. 



2 CONSTANT NEW-DEVICE 



LED ON 
NEW-DEVICE OFF 



We can turn one device on or off without disturbing the 
other. Look at screen #3636. This carries this same example a 
little further, showing how to read the drive's *Index line and 
make the LED go on and off in sync with it. With a disk 
spinning in the drive the LED will flash 5 times a second. 

TIMERS 

The RTX provides 3 on-board timers. They run all the 
time, counting down to zero and automatically reloading 
with the last value stored in them. They can count external 
events, but in this application they just count RTX clock 
cycles. Timers are 16 bits wide. Each can be the source of an 
interrupt or can be read directly. Here's how to set timer 1 to 
count down with a one millisecond time period 

8000 TCll 

This assumes an 8 MHz clock, which gives 8 RTX cycles 
per microsecond and 8000 per millisecond. You only have to 
initialize the counter once, then each time it counts down to 
zero it will automatically reload with the same value. You 
can read the counter with 

TCIS 

which leaves the value on the stack. If you want to find 
exactly how long a group of instructions takes to execute you 
can initicJize the counter before the group and then read it 
afterwards, as follows 

: TIMEIT ( - cycles) 

TCll <group of Instructions to be ineasured> 
TC18 NEGATE ; 

The NEGATE adjusts the down-counting value to the 
number of elapsed cycles. Timer 1 has priority level 8, so its 
interrupt routine would be installed, enabled, and disabled 
as follows 



( Install frcoi the keyboard) 
( install from a definition) 



The timer interrupts are edge triggered. This means that if 
the timer has been running awhile before you enable its inter- 
rupt then an interrupt will be pending. It will wait and wait 
until you finally enable it, and immediately jump to the han- 
dler. So you get an 'extra' interrupt. 

interrupts 

There are lots of interrupts. Five of them are connected to 
external pins Ell through EI5. EI5 is in use on the RTXEB for 
serial communication with the host. The Aligner only uses 
EI3. These are level sensitive, active high. 

Interrupt handling in Forth on the RTX is very easy. On a 



• Tl-INT 8 


1 INTERRUPT 


[ ' ] Tl-INT 8 


1 INTERRUPT 


TIMERl UNMASK 


( enable) 


TIMERl MASK 


( disable) 



regular micro you treat interrupt handlers cautiously. They 
have to be installed just right. Then you must figure a way to 
trigger them to see if the handlers work. You can't just use 
JSR or CALL as the handlers must end in return from inter- 
rupt instructions rather than return from subroutine instruc- 
tions. 

However, on the RTX, the regular return instruction is the 
same for both interrupt handlers and subroutines! This al- 
lows you to call the handler directly-even from the key- 
board-rather than setting up complex test scaffolding. For 
example, here is an interrupt routine to set a variable and 
then disable itself 

I EI3-INT ( -) -1 COMP-FIAG 1 EI3 MASK ; 

It can be tested from the keyboard by setting COMP- 
FLAG to zero then typing EI3-INT. Then reading COMP- 
FLAG, again from the keyboard, to see if it really has a -1 in 
it. In this application, since the store (!) operator does not 
affect the carry flag, nothing needs to be saved and restored. 
This external interrupt (EI3) has a priority level of 10, so the 
above handler can be installed with 



' BI3-INT 10 1 INTERRUPT 
['] EI3-INT 10 IINTERRUPT 



( from the keyboard) 

( within another definition) 



It takes the address of the handler and stores it in the level 
10 slot. EI3 UNMASK enables the routine and EI3 MASK 
disables it. This can be done from the keyboard or from 
within another routine or program. Friendly? Yes. Difficult? 
No. Fast? Ah, that's where the RTX really shines. The latency 
is 1 to 2 cycles (125 to 250 ns with an 8 MHz clock) max and 
the return is usueJly free. 

The Aligner-Hardware Components 

A standard 34 conductor ribbon cable connects the 
Aligner to the drive. This connects the status signals to the 
RTX input port and connects the control signals to the RTX 
output port. In addition, a test clip is used to connect the 
drive's head read amplifier signal to the Aligner. 

Disk Drive Status Signals 

Four inputs are used to read the drive status signals. 
These are »Index, *TrackO, »Write- Protect, and *Read-Data. 
These are active low. *Index pulses low whenever the index 
hole in the diskette is lined up with the hole in the jacket (an 
LED shines through the hole, activating a sensor). This is the 
main synchronization signal. TrackO is low whenever the 
head is moved outward enough to activate the track zero 
switch on the drive (which happens, ideally, whenever the 
head is sitting on track zero). This sensor is a micro switch. 
*Write-Protect is low whenever a diskette in the drive has its 
write protect notch covered. This sensor can either be an LED 
or a micro switch. *Read-Data is the raw read signal that 
pulses low briefly whenever the drive detects a flux transi- 
tion on the diskette. These are all open-collector digital sig- 
nals. The Aligner heis pull-up resistors on its input port so 
that these signals can be read correctly. 



to be continued next issue. 
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Disk Drive Control Signals 

Five outputs are used to send control signals to the drive: 
Direction, Step, Write Data, Write Enable, and Side Select. 
These are all digital signals. The *Motor On and the drive 
select control signals could be connected to outputs, but are 
not; they are hardwired active. 



Signal Conditioner 

Only one analog signal is needed from the drive: from the 
head read amplifier. This is picked up vi^ith a test lead or 
alligator clip (from TPl or TP2 on Tandon drives). After con- 
ditioning and comparing, this will trigger an interrupt on 
EI3. 

The signal we need to condition comes from the output of 



•cr I 3«11 

( DACI write to 8 bit R-2R DAC ) 



: DACI ( u -) 

7 FOR 2* NEXT ( u*256) 

OUT i 255 AKD OR PI ; 

( put it in high half of output port; don't change low half) 

( note that we do not save the dac value in OUT as we do ) 
( for the disk drive control bits - the losrer byte remains ) 
( undisturbed and the lower byte of OUT is still valid. ) 



acr t 3911 

Digital to Analog Conversion 

This system uses an 8 bit DAC built with an R-2R 
voltage divider network, using 47K ohm SIP resistor 
packs. 2R equals 47K and R equals half of that (2 47K 
resistors in parallel). This gives a 256-8tep output 
between GND and the power supply. This is further 
scaled by a fixed voltage divider (lOOK & lOK) to cut 
the output by about an eleventh (a potentiometer could 
be substituted), giving a closer match to the signal to 
be measured. 



A similar result can be achieved by using an integrated 
8-bit DAC. 



Set the output voltage level. 



■cr f 3612 

( EI3-INTW 



interrupt handler used by CLOCK ) 
( save time when each peak starts, starting at PAD) 
( the iDeginning of each peak will trigger this interrupt) 



EI3-INTW ( -) 

TC18 CRS ( time cc) 

1 #PEAKS +1 

IMRC ( time cc imr) 

EI3 NOT IMRl 



( ie mask all interrupts except ei3) 



ROT PAD #PEAKS S 2* + ( cc imr time a) 1 ( cc imr) 



BEGIN 



CM 0> 



TC18 1000 U< 
OR UNTIL 
IMRl CRI ; 



( ie msbit of CR will be set) 

( as long as cranparator is high) 

( ie bail out if timer counts down too far) 

( loop until wave peak goes away) 



•cr « 3912 

EI3 interrupt routine to map windcws for azimuth 
bursts 

EI3-INTH ( ' 'W ' for ''window'') This stores the 
current timer value at PAD and waits for the con^jarator 
to go low again, so we don't count a wave more than 
once. These timer values represet the count -down values 
frctn the start of the index pulse. All of the peaks of 
interest occur in about the 1st two milli-seconds. 

This int handler just stores the values. It is set up 
by CLOCK. Then MARK is used to figure out from these 
times where the azimuth bursts occur. 



•cr # 3«13 

( CLOCK find when azimuth bursts occur ) 
: CLOCK ( - ) 

( set dac so any wave peak will trigger int) 

( clear at least the 1st few bytes for data) 

10 1 INTERRUPT ( install interrupt handler) 

( initialize wave counter) 

( wait for index pulse) 

( start timer and allcw interrupts) 

( 2 milli-seconds is plenty of time) 

{ stop interrupt handler) 



Vb 8 4 + DACI 
PAD 200 ERASE 
( ' ] EI3-INTW 
#PEAKS I 
SYNC 

TCI I EI3 UNMASK 
2 US 
EI 3 MASK ; 



■cr t 3614 

( EI3-INT note it if comparator ever goes active ) 
: EI3-INT ( -) 

-1 COMP-FLAG 1 EI 3 MASK ; 

( this is just about the ideal size for an interrupt handler) 



scr # 3913 

Find when azimuth bursts occur 

CLOCK Set DAC to a value low enough that every wave 
peak should trigger the comparator. Set up the EI 3 
interrupt handler. Wait for the index pulse (SYNC). 
Initialize timerl. Note that timerl is not enabled as 
an interrupt source, but that the EI 3 interrupt 
(connected to the comparator's output) reads timerl to 
find out when the current wave peak occurs. We let it 
run for ''2 MS'' (actually longer because of the time 
spent in the interrupt handler) and then close down the 
operation by masking the interrupt. 

The data we have gathered will be processed by MARK. 



«cr I 3914 

Note whether the comparator ever goes active. 
EI3-INT This Is a very simple interrupt handler. If 
it is invoked (by the ccoparator going active) it notes 
that fact by setting COMP-FLAG true. Then, it disables 
itself. It is used to let us know if the disk drive 
signal exceeded the voltage reference level set by the 
DAC at any time during a particular time interval. It 
turns itself off so it won't be invoked repeatedly 
during the high part of a wave. 



On the RTX, unlike most processors, the return from 
interrupt instruction is the same as a return from 
subroutine. This allows an interrupt handler to be 
tested from the keyboard just like any other Forth 
word! 
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Motor Control with the F68HC11 



Second of a Series 



By Matt Mercaldo 



As I was going through the development cycle for this 
article on driving a stepper motor, I realized how apparently 
complex it is to work with a single board computer. Fortu- 
nately the NMI series of singleboard computer is predictable, 
and when approached logically, works quite well with most 
PCs. This article will serve as an introduction to working 
with the line of NewMicros F68HC11 based single board 
computers. The typical development enviroivment, the as- 
sembler and how Forth does assembly language will be re- 
viewed. Finally a stepper motor will be spun as promised in 
the first article of this series. 

Max-Forlh, a PC and You 

The single board environment has three components: 
source code, a communications program, and Max-Forth on 
the single board computer. All of my development is done 
from the Mac with MicroPhonell by Software Ventures, but 
the principles and settings apply to most platforms and most 
communications packages. I chose MicroPhonell because of 
its powerful scripting language that eases the "pain" found 
in the development cycle of having to dowrJoad modules, 
being attentive to errors and the like. 

The MaxForth Side 

Max-Forth is a Forth interpreter. It accepts characters from 
the serial line at 9600 baud (8 bits, no parity). Characters 
combine to form commands. These commands or Words 
(Words are another name for Forth commands) are deline- 
ated by spaces. A line is interpreted upon reception of a 
carriage return character. Word names can be composed with 
any group of characters other than a space character or a 
carriage return character. Max-Forth echoes all characters 
that it receives. When Max-Forth receives a carriage return 
and interprets the line, it may return a message— it will al- 
ways send a line feed character ( ''J ) last. 

Assume the word HEX is typed at the keyboard of your 
communications program when connected to Max-Forth on a 
NewMicros board. The following sequence ensues: ( '^M is a 



carriage return, '^J is a line feed, _ is the cursor. ) 



character typed 

H_ 

HE_ 

HEX_ 

HEX<cr> 

HEX OK 



Max-Forth ' s echo 
H 
E 
X 
*M"J OK 'M'J 



Matthew Mercaldo is employed by a huge firm. With a small group, he develops 
software tools for field service engineers to do their thing. At 4:30 or 5:00 p.m., 
when the whistle blows, his thoughts race toward the edge. He dreams of articu- 
lated six legged walking beasts, electronic brains that can fend for themselves, and 
the stuff of "U.S. Robots and Mechanical Men." Someday he dreams of running 
power out to his garage, and with his wife and a select group of friends, opening his 
own automaton shop - and thus partially fulfilling his childhood dreams. (Pluto- 
nium, Tritium and the like are still not available for public "consumption"; but 
seeing the moons of Jupiter would be spectacular in one's own starcruiser!) 



The PC Side 

This information on how Max-Forth behaves is very im- 
portant when deciding on a communications program. If the 
communications program could wait for a sent character to 
be echoed, and upon reception of a linefeed ("J character) 
send a new line, a file could be automatically download to 
Max-Forth for interpretation. Most communications pro- 
grams do just that. They can be configured to wait for echoed 
characters and send the next line after receiving a "J charac- 
ter. In MicroPhone II, a carriage return must be sent after the 
line is sent. (I don't really know why this is, but it works!) 

The Source Fiie 

Different text editors maintain text information differ- 
ently. In the typical Mac Edit program, a line is ended with a 
carriage return character only. In other text editors, a line 
feed may be added to form a carriage return, linefeed pair. 
Some text editors put a tab character in the text upon recep- 
tion of a tab character, others put the default number of 
spaces into the text upon reception of a tab character. Two 
things that Max-Forth will not accept are linefeed characters 
and tab characters. Assume that Max-Forth receives 
<tab>HEX<cr> as a new line to be interpreted from a file. 
Max-Forth will try to find <tab>HEX in its dictionary of 
Words - the goal is to find and execute the word HEX. Max- 
Forth will not find <tab>HEX in its dictionary— it will find 
HEX. The same applies to linefeed. (The tab caused much 
anguish when I started to use MicroPhonell. The communi- 
cations package I was using before converted the tab charac- 
ters in my source code to spaces, MicroPhonell didn't. Noth- 
ing would interpret! I thank the programmer who thought 
up Find and Replace! <control> <tab> 
sets the find portion to locate Tab char- 
acters in the find and replace dialog of 
Edit.) 



in Review of Max-Forth, a PC and 
You 

In review, a source file, a communi- 
cations program running on a PC, and 
Max-Forth running on the F68HC11 
single board computer from NewMi- 
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Listing 1. 

COLD 

FORGET TASK 

HEX 

100 IC 1 

50 IE 1 

280 DP 1 

DECIMAL 

20000 CONSTANT /lOMS 

HEX 

' /lOMS e 026 1 



cros are the components required to 
develope software on the F68HC11. If 
the source file has tabs and linefeeds or 
any hidden character in it, they must be 
gotten rid of in the editor, or accounted 
for in the communications program by 
elimination or replacement. Max-Forth 
does not want to see these characters in 
its incoming interpreter stream of char- 
acters. The communications program 
should be configured to wait for the 
echoed character before sending the 
next character, and to send a new line 
upon the communications program's 
reception of a line feed character ("J). 

Forth Assembler, Max-Forth and You 

In a previous article TCJ readers 
were presented with my bias on assem- 
bler. Forth and Forth assembler. With 
the information in that article as a base, 
the necessary assembler basics for this 
project will be reviewed. The basics will 
cover Max-Forth's register usage and 
Data Stack manipulation. 

The Stack and its Usage 

Max-Forth uses a sixteen bit (two 
byte) data stack. This means that data 
objects must be added to or taken from 
the stack in sixteen bit (two byte) incre- 
ments. The desired data object on the 
stack may only be one byte, but upon 
removal, that removal of the data object 
must be in a two byte increment. Max- 
Forth reserves the use of register 'Y' as 
its data stack pointer. If the Y register 
must be used, make certain that it is 
saved going into the assembler routine, 
and restored upon exit of the assembler 
routine. This can be done by the PSHY 
and PULY combination of assembler 
words. 

The 68HC11 puts the least significant 
byte in the high memory location of a 
two byte word. In order to access a 
character on the stack use the following 
as a guide line: 

,Y LDD 



The D register is actually the A and B registers combined. 
The A register is the most significant byte and the B register 
is the least significant byte. With the above operation B will 
contain a character if one is to be found on the stack. When 
removing an element from the stack, copy the element into a 
convenient register and increment the Y register twice. 

,y LDD ( get the stack element into D ; ) 

( A la mab - B Is Isb ) 
INY INY ( update the stack pointer ) 

When adding an element to the stack, decrement the stack 
pointer twice before adding the element:. 



( 2000 ticks of free-running counter 



) 



( Point address 26 at eclock ticks per ) 

( 10 ms. Contents of 26 was supposed to ) 

( time writes to EEPROM but version 3.3 ) 

( F68HC11 has bug — it uses 26 as a ptr. ) 



: EEl ( n addr — ) 
2DUP i = 

IF 2DR0P ( was already equal to n ) 
ELSE 

OVER 100 / OVER EECl 1+ EECl 
THEN ; 



Setting an Interrupt Vector_ 



) 



Define each interrupt handler using CREATE, so that the name 
of the interrupt handler leaves the address of the code. 
Install the handler into the interrupt vector table by 

<code address> <vBctor naine> VECTOR 
For example, to create pulse interrupt handler: 
CREATE PULSAR 
ASSEMBLER 
<code> 
RTI 



Assume that the interrupt vector for PULSE is at address FEEE in the 
68HC11. To get the word >PULSE: 

FFFE i CONSTANT >PULSE 
Max-Forth points the interrupt vectors into the 11 's EEPROM 

To install the PULSE interrupt handler: 
: INSTALL-PULSAR 

PULSAR >PULSE VECTOR ; 
The system reset code should then execute INSTALL-PULSAR. 

: IV ( primary-address <name> — ; define an interrupt vector ) 
<BUILDS , DOES> ( — secondary-address ) t t ; 

FFE8 IV >T0C1 



: VECTOR ( code-addr secondary-vector — ; 
7E OVER EECl ( put jun^ opcode 
1+ EEl ; ( put address 

( Registers in the F68HCll's register map ) 



BOOE CONSTANT TCNT 
B023 CONSTANT TFLGl 
B022 CONSTANT TMSKl 
BO 16 CONSTANT TOCl 
0080 CONSTANT OCIP 



( Free running timer - 16 bit ) 

( Timer Interrupt register - 8 bit ) 
( Timer Interrupt Enable register - 8 bit ) 
( Timer output con^are register - 16 bit ) 
( Interrupt enable flag bit for Timer one ) 



,Y STD 



( update the stack pointer for adding) 

( a new element ) 

( put a new element from D onto the stack ) 



This use of the stack can be found in the code found in 
listing 2. 

Approaches to Inline Assembler 

There are two types of assembler words in Max-Forth: 
Those that Max-Forth can run from the interpreter, and those 
that Max-Forth cannot run from the interpreter. The words 
that Mcix-Forth cannot run from the interpreter are used for 
interrupts and routines supporting interrupt handlers. These 
interrupt routines are comprised of code put into the Forth 
dictionary following a CREATE or CODE Forth dictionary 
header definition. For an excellent treatise on the Forth dic- 
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Listing 2. 

HEX 

( Delay of interrupt ticks before next step state is initiated ) 
VARIABLE DEIAYjriME 10 DEIiAY_TIME 1 

( Offset to be added to TCNT — free running timer — for next ) 
( Timer Output Ccrapare interrupt. ) 

VARIABIiE TIMER OFFSET 100 TIMER OFFSET 1 



( The Motor Control Block 
000 CONSTANT NEXT_MCTOR 
002 CONSTANT ACTION 
004 CONSTANT SENSOR 
006 CONSTANT »PORT 
008 CONSTANT TIMER 
OOA CONSTANT STEP_BIT 
OOB CONSTANT MCB_SIZE 

8000 CONSTANT >PORT 



structure . ) 

( Pointer to Next MCB ) 

( Pointer to an action to carry out ) 

( Pointer to a sensor action ) 

( Pointer to the NMIS 7040 Port ) 

( Pointer to a timer variable ) 

( The active motor bit of the NMIS 7040 

( Size of this data structure ) 

( Pointer to the NMIS 7040 Port ) 



CREATE ANCHOR MCB MCB SIZE AUiOT 



VARIABIiE CURRENT MCB 



The Base MCB for a multiple device 
System. Each Device has its own MCB. 
Each MCB is linked to another. At a 
Regular Heart beat interrupt, this 
MCB is used to Reference the rest of 
the list of MCBs. The list is 
circular so the anchor MCB's action 
will also be fired last. The anchor 
MOB'S action is an RTI. 
All MCB's actions must fire before 
the next interrupt fires. ) 



( This is the currently active MCB during the ) 
( MCB interrupt cycle. ) 



CREATE FIRST_MCB MCB_SIZE ALLOT { The MCB we will use for the NMIS 7040 ) 

{ Stepper motor exan^le. ) 



( Forward References ) 



VARIABLE >_STEP 
VARIABLE >_WAIT 
VARIABLE >LAST_ACTION 
VARIABLE >SENSOR ACTION 



( Enable Interrupts; This word enables all Interrupts ) 

CODE EI ( — ) 

ASSEMBLER 

CLI 

NEXT ' JMP 
END-CODE 



This word disables all Interrupts ) 



( Disable Interrupts; 
CODE DI ( — ) 
ASSEMBLER 

SEI 

NEXT " JMP 
END-CODE 



( _STEP is an Assembler subroutine that Steps the motor one step ) 
CODE _STEP ( — ; uses X, D ;; Jumps to next MCB's action ) 
ASSEMBLER 

CURRENT_MCB " LDX 

( Toggle Step Bit UP ) 

STEP_BIT ,X A LDA 

A ASL 

>PORT " A EOR 

>PORT " A STA 

( Toggle Step Bit Down ) 

STEP_BIT ,X A LDA 

A ASL 

>PORT ' A BOR 

>PORT " A STA 

>_WAIT * LDD 
ACTION ,X STD 

CURRENT_MCB " LDX 
NEXT_M0TOR ,X LDX 
CURRENT MCB * STX 



tionary and dictionary header (and 
Forth assembler) see Starting Forth by 
Leo Brodie. Specifics of the Max-Forth 
dictionary can be found in the New 
Micros Max-Forth Reference Manual Ad- 
dendum. A lot of what is written about 
Forth internals in this article is based 
on the "Max-Forth Reference Manual 
Addendum". CREATE <name of code 
word> or CODE <name of code word> 
simply put a header into the diction- 
ary. When the <name of code word> 
name is interpreted, it puts the address 
of the next available byte in the Forth 
dictionary (when it was compiled) 
onto the data stack (This pointer is 
refered to the parameter field pointer 
or PFA in Forth lingo). The postfix 
Forth assembler starts laying down the 
opcodes at this address immediately 
after the creation of <name of code 
word>. These type of words end in ei- 
ther RTI for an interrupt return, or RTS 
if they have been called via JSR or BSR. 

To Spin a Motor 

The code in Listing 2. is our motor 
control code. The code is thoroughly 
documented. But at times documenta- 
tion can only carry the cradle of under- 
standing so far. Two concepts are fun- 
damental in understanding this model 
of stepper motor control. Concept one 
is that a regular interrupt "heartbeat" 
propels this system. Concept two is 
that this system broken into states. 
Concept two leads to the definition of 
the Motor Control Block (MCB) and 
the factoring of states into little—quick 
subroutines; one of which is fired on 
each regular interrupt. 

The Motor Control Block 

The MCB is the fundamental data 
object in our system. It defines the next 
action to take on interrupt. This action 
is one of two events for our current 
application: stepping the motor or 
waiting. The sensor action points to a 
subroutine which looks at the sensors 
associated with this motor and per- 
forms a regular sensor update func- 
tion. If an encoder was connected to 
this MCB's motor, the sensor action 
would update encoder ticks in a vari- 
able within the MCB. The MCB is 
where all of this motor's data is main- 
tained. (Just because you don't see it 
doesn't mean it cannot be added). The 
address of the motor as connected to 
the NMIS 7040 module is maintained 
in the MCB, etc. 

This MCB is in a linked list of 
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MCBs. With this model, each motor 
within the list maintains its own con- 
text or all of that data specific to this 
motor. Three motors can be run simo- 
taneously, while processing other 
events—like a communications network 
with a master processor by this ap- 
proach. The model found here is the 
basic model used for asynchronicity in 
advanced robotics applications and de- 
vice drivers. In the context of this list of 
MCBs there exists an Anchor MCB. 
This is the first and last MCB. The list is 
accessed via the Anchor. The first Mo- 
tor MCB is referenced from the Anchor 
MCB. The Anchor MCB's action is not 
tired first. When all of the MCBs iiie 
for this interrupt, the anchor MCB's ac- 
tion is fired. The Anchor MCB's action 
is an RTI; the way out. 

You may seem a little confused 
now, especially if you have looked at 
the assembler words _STEP and 
_WA1T. Remember concept 2 from 
above. The motor run instance needs to 
be broken into states. The goal of this 
article is to spin the motor.ln order to 
spin a motor the motor needs to be 
stepped. Two states are required to 
step the motor. State one _STEPS the 
motor, state two _WAITs for the motor 
to settle. Since this thing is based on 
the heartbeat or timed interrupt, the 
settle time must be controlled. (In the 
next article we will control the settle 
time to accelerate and decelerate the 
motor). If the motor were to step on 
each interrupt (32 milliseconds apart), 
the motor would chatter. This articles 
goal is to spin the motor—chattering 
will not do. While in the WAIT state, 
each interrupt decrements this motor's 
TIMER found in the MCB. When the 
settle time has elapsed as per TIMER, 
the state is changed to _STEP and the 
timer is reloaded for the next _WAIT 
state.The next time around, the motor 
will be stepped, and the state set back 
to the _WAIT state. 

The Next time around? 

I hope the confusion is becoming 
less confusing.. Lets look at the se- 
quence of code which completes each 
state. 

CURRENT_MCB " LDX ( get currently ) 

( active MCB In X ) 

NEXT_MOTOR ,X LDX ( get the "next ) 

( MCB to fire' ' in X) 

( thru this MCB ) 

CURREHT_MCB " STX ( make the ' ' next ) 

( MCB to fire" the ) 

( current MCB ) 

continued page 38 



,X JMP 
END-CODE 

STEP CFA i >_STEP 1 

( Waits a specific time between steps ) 

CODE _WAIT ( — ; uses X, D ; ; Jumps to next MCB's action ) 

ASSEMBLER 

PSHY ( Save Max-Forth ' s data stack pointer ) 

CURRENT_MCB ' LDX 
TIMER ,X LDY DEY 
EQ IF 

DELAY_TIME ' LDD TIMER ,X STD 

>_STEP " LDD ACTION ,X STD 
ELSE 

TIMER ,X STY 
THEN 

PULY ( Restore Max-Forth 's data stack pointer ) 

CURRENTMCB ' U)X 
NEXT_M0TOR ,X LDX 
CURRENT_MCB ' STX 

ACTION ,X LDX 
,X JMP 
END-CODE 

WAIT CFA t > WAIT 1 



— Anchor MCB's — action ) 

( — ; Returns from processing interrupt ) 



( The last MCB's 
CODE LAST_ACTIOM 
ASSEMBLER 

RTI 
END-CODE 



' LAST_ACTION CFA t >LAST_ACT10N 1 

( A stub for future sensor update actions ; ; i.e. encoders , etc . ) 

CODE SENS0R_ACTI0N ( — ; Must be called via JSR ) 

ASSEMBLER 

RTS 
END-CODE 

SENSOR_ACTION CFA i >SENSOR_ACTION I 

Output Compare Timer Interrupt handler routine Specific to Output 

Con^are Timer 1 ) 

This Interrupt Routine will process the list of MCB's. 

The list must be circularl 1 1 ANCHOR -> FIRST -> ... -> LAST -> ANCHOR 

The Anchor MCB's action must end with an RTI. 

All other MCBs must get the next MCB's action and execute it: 

Effectively. . 

Get next MCB in list into X 

Hold onto this in CURRENT_MCB for next routine 

Load a pointer to the Next Mcb ' s Action into X 

Execute Next MCB ' s Action 



... NEXT_M0TOR ,X LDX 
CURRENT_MCB ' STX 
ACTION ,X LDX 
,X JMP 
Sets up to the next MCB 
CREATE -M0TOR_HANDLER ( - 
ASSEMBLER 

OCIP # A LDA 
TFLGl " A STA 



) 



uses X, D 



Processes list of MCB's ) 



( Acknowledge Interrupt. ) 



TCNT ' IDD 
TIMER_OFFSET 
TOCl ' STD 



AOOD 



( Set Up for next interrupt ) 

( based on Interval from TIMER_OFFSET. ) 



( Get Anchor ) 

( Get First Motor from Anchor ) 

( Set as first Motor ) 

( Do First Motor's Action ) 



ANCHOR_MCB # LDX 
NEXT_M0TOR ,X LDX 
CURRENT_MCB ~ STX 

ACTION ,X LDX 
,X JMP 

( End of -MOTOR_HANDLER ) 



INITIALIZE_MOTOR ( — ) 

( Connect last block to itself and connect last action ) 
ANCHOR_MCB ANCHOR_MCB NEXT_M0TOR + 1 
>LAST_ACTION t ANCHOR_MCB ACTION + I 
( set the interrupt vector ) 
-MOTOR HANDLER >T0C1 VECTOR ; 
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Controlling Home Heating and Lighting 

A Personal Embedded Controller System 



By Jay Sage 



Although most TCJ readers are famihar with my regular- 
column on Z-System software, I actually got my start in mi- 
crocomputing with controllers. Ever since editor/ publisher 
emeritus Art Carlson began asking for articles on embedded 
controllers, 1 have thought about describing my very first 
computer project, an Intel 8085-based controller that has been 
operating the heating and lighting systems in my house for 
the past decade. 

Background 

In the late 1970s 1 was working in Raytheon Company's 
Research Division developing charge-coupled devices 
(CCDs) for analog signal processing. To facilitate the meas- 
urement of field-effect semiconductor devices, I designed a 
number of test boards that used analog integrated circuits 
(especially operational amplifiers) and small- and medium- 
scale digital logic circuits. 

At the time, Raytheon sponsored some Summer short 
courses at Cornell in various electrical engineering subjects. 
One of them was an introduction to the then new micropro- 
cessor chips. In return for its support, Raytheon was allowed 
to send one employee to attend the course. I was offered the 
opportunity; it sounded like fun, so I accepted. I enjoyed that 
course so much that on my return I started immediately on 
the design of a microprocessor-based system that would op- 
erate the electrical circuits in our house. 

Why did I choose that application? A couple of years ear- 
lier, our house had been broken into, and to discourage bur- 
glars from a repeat performance, we put clock timers on half 
a dozen of our lamps. It was quite a nuisance, however, 
when a timer would turn off the only light in the room amd 
we would have to crawl around on the floor in the dark 
trying to find the timer. The computer controller would make 
life easier by working in parallel with the regular light 
switches. 

In addition, we were still in the aftermath of the 1973 oil 
crisis, and I thought we could greatly reduce our oil con- 
sumption by having the computer controller operate the elec- 
trical circuits in the heating system. Ultimately, this is where 
the system has really been productive. 

It is going to take a couple of columns (at least) to describe 
this whole project. This time I am just going to lay the 
groundwork; next time I will get into the details of the com- 
puter circuit. Although the circuit was designed and built 
more than ten years ago, and I would do a number of things 
differently today, the basic concepts are, I think, still sound 
and instructive. 



The Basic Functions 

The functionality of the controller that is visible to the user 
is basically a flexible scheduler. It stores the day and time 
when actions are to take place. It also knows about various 
conditions, such as whether we are at home or away and 
whether it is an ordinary day or a vacation period. Scheduled 
events can depend on combinations of those conditions. 

Two kinds of actions are supported: (1) turning electrical 
circuits on or off and (2) setting the thermostat for the heat- 
ing system. Electrical circuit switching is actually controlled 
in two ways. The obvious way involves turning circuits on 
and off at specific wall-clock times. A second stored schedule 
turns circuits on and off at times relative to the onset of dark- 
ness outside, as determined by monitoring a photocell. I gen- 
erally turn lights on based on outside brightness and turn 
them off based on wall-clocktime. In this way, the schedule 
does not have to be revised with the change of seasons. Also, 
lights will turn on automatically during dark rainstorms (and 
off again when the storm clears). 

We will share more specifics about the operation of the 
controller next time. For now we will continue with a discus- 
sion of the internal control strategy used to operate the heat- 
ing plant. 

l-leating Controi Concept 

Our house, like many in New England, uses an oil-fired- 
boiler to heat water that is circulated by a pvmip through 
radiators (cast iron in our case). A thermostat senses the air 
temperature and turns on the circulator when the room air 
drops below the set temperature. 

The temperature of the water in the boiler is similarly 
regulated by what is called an aquastat. While the thermostat 
could be set back at night, either manually or automatically, 
the aquastat always has a fixed setting. In order to ensure 
adequate heat on the coldest day possible, the water tempera- 
ture is generally kept at a very high setting, perhaps 180 de- 
grees Fahrenheit (80 Celsius). Day and night. Warm weather 
and cold. 

And what does all the hot water in the boiler do while it is 
sitting around waiting to be circulated to the radiators? Well, 
for one thing, it leaks its heat into the basement. Our base- 
ment being unfinished, this is nearly a complete waste. Sec- 
ond, it sets up a nice convection up the chimney. This liter- 
ally sucks heat up the chimney, cooling off the water in the 
boiler and drawing fresh cold air into the house. More waste! 

Besides being inefficient, this control strategy also pro- 
vides less comfort. After the air in the house cools, the circu- 
lator comes on, bringing very hot water into the radiators, 
which then transfer their heat into the air. Soon the room has 
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weirmed up and the circulators shut off. But, the radiators are 
still nice and hot, eind they keep pouring heat into the room. 
The room gets much hotter than the thermostat setting, and 
during the long cooling down time with no heat, the rooms 
tend to have cold drafts. Not very nice! 

The best thing to do, I thought as a physicist, was to con- 
trol the water temperature so that the radiators were at just 
the right temperature to transfer heat into the air at the exact 
rate heat was leaking out of the house. The circulators could 
run continuously. On warmer days and at night, when the 
thermostat setting was low, the boiler water would be quite 
cool, and the losses, both into the basement and up the chim- 
ney would be much less. Also, there would be almost no 
swings in air temperature, and the steady low-level heat 
from the radiators would inhibit drafts. 

Simple, linear heat conduction theory implies that the 
boiler temperature would have to exceed the desired (and 
actual) air temperature by some factor times the amount that 
the £iir temperature inside is to exceed the air temperature 
outside, that is 

( Tb - Ti ) = K • ( Ti - To ) 

or 

Tb=(K+l)*Tl-(K*To) 

where Tb is the boiler temperature, Ti the inside air tempera- 
ture, and To the outside air temperature. The factor K de- 
pends on the amount of insulation in the house and the effec- 
tiveness of the radiators (big cast iron radiators are great; 
baseboard units are pretty poor). 

More Sophistication 

Once one has a microprocessor running things, one might 
as well really put its processing power to work. I, therefore, 
applied some more sophisticated control strategies on top of 
the basic one described above. 

If the aquastat is set exactly at the temperature required to 
■ maintain the steady-state air temperature desired, then there 
will be no excess capacity to allow the house to Wcirm up 
when the thermostat setting is increased. Therefore, an addi- 
tional correction is included in the aquastat setting in propor- 
tion to the difference between the desired air temperature 
and the actual current air temperature. The equation thus be- 
comes 

Tb = (Kl + l)*Ti - (Kl • To) + K2*(Tb - Ti) 

where Ts is the thermostat setting. 

Adding this term has several benefits. It allows the house 
to warm up during programmed increases in temperature 
(Ts-Ti > 0), as we just said. It also allows the boiler to remain 
extra cool during programmed decreases in thermostat set- 
ting (Ts-Ti < 0). Finally, it enhances the stability of the system 
agmnst errors in the control parameters. 

Cycling an oil burner on and off is not good for efficiency. 
During the first several minutes of a bum, while the combus- 
tion chamber (fire box) is still cold, the oil does not vaporize 
well and, therefore, does not burn as well. There is less heat 
and more soot, which builds up on the heat exchanger and 
impedes heat transfer into the water. 

The best thing would be to have a variable-firing-rate 
nozzle. Then one could keep the flame on continuously and 
regulate its heat production to match exactly the leakage rate 
from the house. Today there are gas-fired boilers that work 



somewhat this way. As far as I know, this has never been 
done with oil. I suspect that burning oil is a tricky process 
and that nozzles are carefully optimized for a particular flow 
rate. Building £tn efficient variable-flow-rate nozzle may not 
be feasible. 

My compromise was to use a nozzle that provided just a 
little more heat than would be needed on the coldest possible 
day. Experiments showed that I could change to a nozzle 
with only half the flow rate of the one that had been in the 
boiler! With a small nozzle, firing times are longer, and the 
inefficient bum time is a smaller fraction of the total bum 
time. 

Naturally, we want the house to be quite cool at night, 
and there is no sense keeping the boiler warm during that 
time. Therefore, the controller is programmed so that when it 
sees a decrease coming in the desired air temperature, it 
automatically decreases the aqusistat setting and allows the 
radiators to extract as much heat as possible. Typically, by 
the time we go to bed at night, the boiler is down to only 
about 25 degrees C, barely above room temperature. 

This in turn introduces a new problem. With the boiler so 
cold overnight and such a low firing rate, if the system 
waited until the thermostat setting came back up to turn on 
the boiler, it might be many hours before the house would 
catch up. The controller is, therefore, made to look ahead and 
to compute the time to begin firing so that the house tem- 
perature reaches a future programmed temperature at ex- 
actly the time it is programmed for. On a really cold day, the 
boiler begins firing three or four hours ahead! 

Normally the boiler is cycled on and off in response to the 
computed aquastat setting. If one used a single temperature 
set point, of course, the oil burner would turn on and off 
frequently, so, as with standard mechanical thermostats and 
aquastats, some hysteresis is included to stabilize this. In 
other words, the tum-off setting is slightly higher than the 
turn-on setting. 

In addition, since the early firing of the burner is less 
efficient, the controller is programmed to give a minimum 
bum time, once firing has started, independent of aquastat 
setting. I figured that it was better to have the water slightly 
hotter than necessary sometimes rather than have short bum 
times. Water condensation in the cool chimney and boiler 
parts could lead to corrosion. The minimum burn time was 
chosen to ensure that the boiler flue temperature would 
reach at least 100 C. 

There is a worry one always has with a circulating water- 
heating system—freezing. If there is a pipe near an outside 
wall, and if the circulator is off for a long period of time, and 
if the weather is very cold, a section of the pipe may freeze 
and possibly burst. This makes for quite a mess (especially if 
you haven't disabled the automatic water filling system, as I 
have). To prevent freezing, the software turns on the circula- 
tor for a short period of time after a maximum off interval 
even if no heat is needed. 

As I mentioned earlier, with the control strategy imple- 
mented here, the circulator can run nearly continuously. In 
fact, that is exactly what happened with an early version of 
the software, and we noticed a substantial jump in our elec- 
tric bill because of the energy consumed by the motor. 

I then reasoned that it should be adequate to turn on the 
circulator only long enough to exchange the slug of water in 
the radiator for a new, warm slug of water. So long as the 
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Getting Started in Assembly Language 

Making the Jump from High Level Languages 

by A. E. Hawley 



Why would anyone who programs in a high level lan- 
guage (HLL) want to learn assembly language, especially 
considering its reputation as "difficult and too detailed?" 
One reason is precision, another is power. Given program- 
mers with equal skills, a program written in assembly lan- 
guage will be both faster and smaller than one written in a 
high level language. Can you think of a way to write a pro- 
grara which will load and execute at the highest available 
location in memory without disturbing one in low memory? 
You can do it with a good assembler and linker. It is very 
difficult to do in most high level languages. 

John Poplett, as sysop of the "Plaster of Paris BBS", ca- 
tered mainly to writers and literature buffs. John himself was 
a technical writer who had learned BASIC, gotten acquainted 
with ZCPR3, and had set up his BBS with the venerable RBBS 
system. He was a frequent caller on my Z-Node, always ea- 
ger for the latest utility updates. We chatted often about the 
workings of the CP/M operating system and ZCPR3. One 
day, he decided that he needed to be able to understand in 
much more detail how things worked. He wanted to learn 
AL (Assembly Language) and wanted some advice on how 
to go about it. He picked a goal, and six months later the first 
version of ZLUX was released. 

This article includes the advice that John Poplett used in 
his climb from "rags to riches" (intellectually, at least). It is 
introductory, intended for the average user familiar with one 
or more high level languages. Perhaps you, too, want to un- 
derstand AL programming. 

What do you need to get started? You probably already 
have some of the software lurking in your archives. You will 
need an editor, an assembler, and a debugger. Of course, if 
you never make misteaks you have no need for a debugger, 
Wright? 

Choosing an Editor 

If you have done HLL programming, then you have an 
editor and will prefer it. The main requirement is that the 
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editor be used in a mode that produces straight ASCII files. 
Assemblers just can't cope with the meaning of formatting 
commands and embedded control characters. Many pro- 
grammers use Wordstar in the non-document mode. An ex- 
cellent public domain editor that uses the Wordstar com- 
mand syntax is ZDE, by Carson Wilson. ZDE is much faster 
than Wordstar because it does not page its files to and from 
memory. Wordstar (or some other) must be used if your file 
becomes too large to fit into available memory. I started 
years ago with MATE, graduated to PMATE and then to 
ZMATE. If you need to buy an editor for programming use, 
ZMATE is the one I recommend. 

Assemblers 

The assembler you use should be a relocating macro as- 
sembler that accepts Z80 mnemonics and can produce HEX 
and Microsoft REL output files. Bruce Morgen (reference 3) 
compeires assemblers and linkers from DRI, Microsoft, and 
SLR. The DRI RMAC assembler, as he points out, uses Intel 
8080 mnemonics but is otherwise acceptable. Through use of 
the public domain Z80.LIB, RMAC can be made to produce 
Z80 code but at the expense of non-Zilog mnemonics. The 
differences make your source file incompatible with assem- 
blers that use Zilog mnemonics. If you use RMAC, be aware 
that you will have some translating to do when you try to 
assemble files (from the public domain, for example) written 
in Zilog mnemonics. 

Bruce did not include the ZMAC assembler and ZML 
linker in his review because they were released a year later. 
ZMAC uses Zilog mnemonics, is CP/M compatible, uses 
ZCPR3x if it is present, and has a superset of M80 capabili- 
ties. It is the only Z80 assembler that is currently actively 
supported. This assembler handles HD64180 as well as Z80 
instructions. ZMAC is much faster than M80 and about the 
same speed as the SLR assemblers in their two-pass mode. 
The ZML linker makes the generation of PRL and SPR files as 
simple as a command line option and can easily produce RSX 
files. Similarly, making ZCPR34 Type 4 files is a function that 
you simply invoke. Type 4 files execute 
at the highest possible memory ad- 
dress, just below ZCPR34. 

If you have ZAS/ZLINK, go ahead 
and use them until you can get some- 
thing better. They have some "fea- 
tures" that will eventually make you 
wonder if you really understand as- 
sembly programming! (be assured, you 
do..) 

I have all of the above. Naturally, I 
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use ZMAC most of the time. Z80 source files written for M80 
can be assembled by ZMAC or the SLR assemblers. I reserve 
RMAC for those public domain programs written for it when 
I don't want to bother with translation to Z80 mnemonics. 

Debuggers 

Bruce Morgen also reviewed debuggers. He reported DSD 
as the premier Z80 debugger. I have it, use it regularly, and 
agree that there is nothing finer in its field except its big 
brother Remote DSD. DSD is indeed available. Sage Mi- 
crosystems East can supply it, as well as ZMATE and 
ZMAC/ZML. 

You will find a symbolic debugger program very useful. 
Symbolic debuggers use the symbol table produced by link- 
ers to allow you to single-step through the executing code, 
displaying the state of all registers and memory contents in 
terms of the symbols you assigned in your source code. A 
good public domain debugger, available on many remote 
access systems, is Rick Surwilo's Z8E. This symbolic debug- 
ger, like DSD, is screen oriented, versatile, and of profes- 
sional quality. Cam Cotrill, one of the authors of ZSDOS, 
used Z8E on many software development projects until he 
discovered DSD. 

Things You Need to Know 

Now you have the basic software tools, and you have read 
the ir\structions provided with them. (You have read them, 
haven't you?) What else is there? Assembler documentation 
usually assumes that you are familiar with the basic mathe- 
matical, logical, and physical principles on which the opera- 
tion of your computer is based. This awareness is the guide 
that you use to select and organize the ir«tructiorw that com- 
prise an AL program. Here's a list of subjects that are impor- 
tant: 

How a CPU works 

Architecture for Z80, Z180/HD64180 

Data, Address, Control lines 

Machine commands and Machine language programming 
How information is organized in a computer 

Bits, Bytes, Words, Addresses, and Memory organization 
How data is manipulated 

Binary arithmetic- Add, Subtract, Multiply, Divide, and 

SHIFT 

Boolean algebra-AND, OR, XOR, NOT and Truth tables 
Assembly language programming 

Assembler Mnemonics 

Assembler Pseudo-ops. How they differ from Mnemonics 

How a CPU Works 

The final answer to questions about how a microprocessor 
works is contained in the manufacturer's data sheet. Refer- 
ences 1 and 2 point you to the right phone numbers to call to 
get the data sheets for the Z80 and its newer brother the 
HD64180 (Z180, from Zilog). Some electronic supply houses 
can also supply these. In either case, be pleasantly surprised 
if they are free. You should have one of these in your library, 
depending on the CPU your computer uses. Books on pro- 
gramming contain the same information, paraphrased smd 
edited. 

Machine Language Programming 

The first widely available microcomputer was the Altair. 



It had a front panel with rows of LED lights and switches. 
The LEDs monitored the CPU control bus, the data bus, and 
the address bus. Sixteen of the switches were used to specify 
the address for the next operation. Eight of these switches 
provided data for the data bus. Other switches controlled 
running, stopping, single stepping, and storing data bus con- 
tents at the current address. With this primitive setup, the 
user could store bytes contiguously in memory to form an 
executable program, then execute the program in single step 
or run mode. Typically, the very small program so tediously 
entered would simply read bytes from an I/O port and de- 
posit them in memory. When done reading, a jump instruc- 
tion caused the new block of code to be executed, and voila! 
BASIC, or a monitor, or simple editor/assembler came alive. 
Your computer starts up the same way! The front panel 
has been replaced with two switches: the power switch, and 
the Reset button. The initial bootstrap code is in ROM, auto- 
matically invoked when power is turned on or the reset but- 
ton pushed. With all debuggers, you can simulate the origi- 
nal method of programming without getting calluses on your 
fingers. You use the "S" command to enter bytes where you 
wish in memory. You specify the bytes in hexadecimal, but 
some debuggers allow you to specify them in binary or AS- 
CII as well. Then you can use the "GO" command to execute 
the code, or a "T" to single step through the code. At any 
point, you can observe the contents of the CPU registers and 
memory locations. This is the first step toward a high level 
language. An assembler is the second step. 

Bits, Bytes, Words, and Addresses 

Your computers CPU processes data using byte-based bi- 
nary boolean logic operations, shifting operations, and copy 
operations. Integer arithmetic operations are actually micro- 
programs within the CPU, and are executed like the ex- 
amples of binary arithmetic you can do by hand (the long 
hard way). Single-bit operations can be visualized as boolean 
byte operations in which bits other than the bit being ad- 
dressed are either unaffected or are all set to either or 1. 

The CPU logic operations provided are AND, OR, XOR, 
and NOT. The NOT operation masquerades in the CPL in- 
struction, which simply inverts all the bits in a byte. The 
arithmetic operations are ADD and SUBtract, with variations 
depending on the treatment of the carry bit and extension to 
operations on 16 bit words. 

If you eire at all hesitant about these subjects, by all means 
look to books like references 7,8, and 9. The Intel 8080 Assem- 
bly Language Programming Manual (reference 10) discusses the 
arithmetic and logic instructions in great detail, illustrating 
them clearly in binary. The Zilog and Hitachi publicatior\s 
assume that you are already familiar with such basic theory. 
The owners manual for the Altair computer (if you can find 
one!) contains a clear discussion of these principals although, 
of course, it is limited to 8080 ir\structions. The Z80 had not 
yet been developed! 

From Machine Language to Assembler 

In the first step toward higher level programming manual 
operations (flipping switches) are replaced in the debugger 
by much less tedious typing of hex bytes. A second level of 
abstraction occurs when you use the simple in-line assembler 
that most debuggers contain to enter the mnemonics for ma- 
chine instructions (like LD A,0). Note that numeric values 

continued page 37 
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REAL COMPUTING 

The PC-532, Minix 1.5, and the 32GX320 



By Richard Rodman 



My PC-532 is up! 

The basement is small, but that's no obstacle to its looking 
like the lab from Bride of Frankenstein. A web of cables blan- 
ket the floor. The patient lays atop a makeshift table. Meters 
and probes are precariously balanced over the exposed cir- 
cuitry, bathed in the cold phosphorescent glow of the moni- 
tors. He sweats as he tirelessly moves his probe from point to 
point-no signal, no signal, no, ... "More POWER! 1 need more 
POWER!" 

A sudden flash of lighting silhouettes him against the 
casement windows. An LED flickers! The monitor stirs! He 
jumps up and throws open the window. "It's ALIVE!" he 
screams into the dark rain that pelts him in the face. "It's 
alive." He stands, laughing and sobbing, soaked by the rain, 
as the lighting flashes, the thunder booms. 

What can match that supreme joy, that feeling of sublime 
affirmation, that incredible, indescribable pinnacle of 
achievement when the object of one's simultaneous bound- 
less love and bottomless hatred, one's most enticing tempt- 
ress and fiendish enemy, after hours, days and months of 
unflagging pursuit, tmtold perils and changes of strategy, 
finally gives in and works! 

What I'm getting to is that my PC-532 is now up. It was 
actually a struggle more against ambiguous documentation 
than anything else. For one thing, there are 8 SIMM sockets. 
To install only 4 SIMMs, you use the even-numbered (every 
other) sockets. For another thing, the console connector is J3. 
The documenter must have assumed that these facts were too 
obvious to merit inclusion in documentation, but he forgot 
the first law of documentation: Nothing is obvious. 

Anyhow, the PC-532 has the greatest ROM monitor I've 
ever seen. It was written by Bruce Culbertson and includes— 
get this—on-line help! In these days of cheap ROM, it's about 
time. The monitor supports breakpoints, single-step, instruc- 
tion disassembly, and a lot of other nice features. It includes 
a simple binary download protocol. It was a simple matter to 
modify my HOST program to support this protocol too. Us- 
ing this downloader, following Bruce's instructions, I was 
able to set up a RAM-disk and bring up Minix 1.3 on the PC- 
532. I don't have any disk on the system as yet, however. 

By the way, a couple of issues back I mentioned that the 
OMTI 5200 board is available, but left a funny symbol as to 
who it was available from. Actually, this is an older control- 
ler. A newer model, the 7200, is available from Arrow Elec- 
tronics. There are some variations in different models. The 
model 7200 can interface up to 4 floppies and 4 MFM hard 
disk drives to the SCSI bus. 

Getting back to the monitor, it's made up of a combina- 
tion of assembly and C. Bruce has been using GCC (the Gnu- 



C compiler) which he has running under Minix. I haven't 
been able to rebuild it as yet using the tools I have available, 
but would suggest that this monitor would be better than 
SRM or TDS as a standard for home-brew NS32 systems. 

Minix 1.5 

Minix 1.5 is no academic exercise. This is a full-featured 
operating system, with more system calls and utilities than 
version 7 Unix. It runs quickly and smoothly, supports all the 
various floppy formats of the PC, and is well documented. 
It's actually even better than I expected it would be. It came, 
in my case, on 12 720KB 3-1/2" floppies. 

It's almost amazingly audacious to come out with a pro- 
gram available on the PC, the Atari ST, the Amiga and the 
Mac, all at the same time— but an operating system! It's a 
potential customer support nightmare. A mere word proces- 
sor has a cushion of device-independent code under it; an 
operating system has to work right on the bare metal, and 
some pretty quirky bare metal it is, too. But they're doing it; 
call them at the numbers below if you have trouble. Obvi- 
ously, OS hackers are made of better stuff than your average 
1-2-3 user. It appears from Usenet that Mac users have had 
some difficulties running Minix under Multifinder. I had two 
bad floppies, which Prentice-Hall replaced cheerfully. But, at 
least on the PC, this is a very stable product. 

To misquote Stan Kelly-Bootle, into each china shop some 
bull must fall. I had some problems with Minix 1.5. After 
going though 8 pages of installation procedure in which, all 
along, they assure you it can be installed with the hard disk 
as the root (not using a RAM-disk), the setupusr shell script 
cannot dismount the hard disk, so it won't execute, and the 
software can't be installed. This means that you have to stetrt 
completely over and re-partition the hard disk. Remember: 
you must use a RAM-disk. 

On the bright side, Minix's fdisk program is tremendously 
better than DOS's. Having used it, I wonder how Microsoft is 
getting away with nationwide distribution of such a shlock 
partitioning program. DOS's FDISK is cumbersome, limited, 
confusing, error-prone, and clunky, and hasn't been im- 
proved at all since they came out with it 5 years ago. They 
ought to be ashamed. 

Minix also includes a network driver for the Amoeba 
protocol. It includes drivers for a couple of common Ethernet 
boards. This means that networks of Minix systems are now 
possible. And, of course, source is included. About all you 
don't get is X window. The way things are going, someday 
maybe AT&T will brag about having a Minix-like operating 
system. 
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More information on the 32GX320 

I've received some more information on the new proces- 
sors in what is now called the Series 32000/EP. First I'd like 
to go into what I think is the more aimazing of the new chips, 
the 32GX320. 

As mentioned before, this chip is a superset of the 
32GX32. It does not have, nor support, a memory manage- 
ment unit. It does have an on-chip interrupt controller, DMA 
controller, and some new instructions. It also has some hard- 
ware assistance for existing instructions. 

The on-chip interrupt controller is not as fancy as the 
32202, but it has what most people need. It includes 3 16-bit 
timers. The logic is mapped into memory at FFFFFEOO and at 
FFFFF800 (don't you love these 32-bit addresses?). The timers 
can count external signals and can also generate system tim- 
ing outputs. The data book (it can hardly be called a "sheet") 
notes that "from the CPU standpoint, the on-chip ICU can be 
regarded as an independent module." 

The DMA controller has two identical and independent 
channels. Each of these are capable of operating in several 
modes. The fastest mode is what is called "flyby" mode. In 
this mode, both an I/O device and memory are selected si- 
multaneously, and the data is transferred in a single bus 
cycle. DMA controller channels may also be used for trans- 
ferring memory blocks within the system. The DMA control- 
ler is mapped into memory at FFFFFOIO and up. 

How about the new instructions? The first one is 
MULWD, a 16x16 multiply which is functionally the same as 
MULW, but around three times as fast (200ns). MULW is still 
available if you want to use it. The next is CMULD, complex 
multiply double. The two operands of this instruction are 16 



bit real part in the low-order word, and 16 bit imaginary part 
in the high order part. The result (32 bits each real and imagi- 
nary) does not replace either operand but goes in registers RO 
and Rl. Another complex math instruction is CMACD, com- 
plex multiply and accumulate double, which is like CMULD 
except the results are added to the previous RO and Rl con- 
tents. Finally, there's MACTD, multiply and accumulate 
twice double, which is a kind of vector dot product. 

Shift instructions on the 32GX320 are sped up by a barrel 
shifter. There's no new instructions, though; the normal in- 
structions just run faster. 

The chip is available either in a 208-pin flat pack or in a 
175-pin PGA. No, it's not pin compatible with the 32532 or 
the 32GX32. The data book number is item 114303. This is a 
hot chip. Let's hope National can get a bunch of these into 
the hands of experimenters out there. 

Next time 

Next time, we'll have the details on the 32FX16 and a 
couple of other fax-related products. Plus, the old dog's next 
new trick: the 486 has a crude cache. In the meantime, when 
you hear someone describe their product as "open", keep 
your eyes open and your wallet shut.# 

Where to write or call 

Minbc: Pr«ntice-Hall Voice; 1-800-624-0023 

Microservice Customer Service 1-201-767-5969 

Simon & Schuster BBS: 1-703-330-9049 
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Z'SUS... 



Z-System 



Software Update Service 

Bringing the Z-System World Closer Together. 



Once upon a time, before the coming of the Corporate 
Market, microcomputers were not Just owned by 
individuals. They were built and programmed by 
individuals. We were an ignorant lot back then. We never 
thought to ask if a machine could do something -we Just 
plugged away at the task until it did! Those innocent days 
are gone forever, replaced with $500 text editors, exploding 
windows in gaudy colors and simple utilities expanded 
past 1 00k in objectform. There is no room for the 
individual anymore. 

Or is there? 
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Z-SUS... 

Bringing the Z-System World Closer Together. 

Reenter the exciting world of truly personal computing. 
The cost is small: a Z80 computer, a new operating 
system and time. Learn what others have never forgotten, 
that the spirit of the individual made this industry. 



Z-SUS Catalog Disk: 

An in-depth catalog oi Z-SUS offerings, available only 
on disk. Besides providing you with a detailed explana- 
tion of every service and package we offer, the Z-SUS 
catalog disk also includes the most current copy of 
ZFILEV.LST by Bill Tishey. To this, we've added Gene 
Pizzetta's XFOR.COM, adapted and renamed to DF.COM 
(Describe Files). Use it to look up the name of any Z- 
System toolbyany criteria you wish. For example, to find 
files relating to shells, you would enter: 
AO>DF SHELL 

Now you can quickly search for just the tool you need 
to solve any problem at hand. 

Price: $ 2.00 

Foreign Shipping Surcharge' : 2.00 

Z-SUS Subscription: 

The guaranteed way to stay up-to-date with the latest 
public domain Z-System software. Most include source 
code. The subscription disks are issued approximately 
once per month. Start your subscription at any point you 
like. Just tell us on your order form where to begin. 

We are always looking for good software. If you know 
of a release deserving worldwide distribution, send it in! 
Price, 12 issue subscription: $72.00 
Price, 6 issue subscription: 48.00 

Foreign Shipping Surcharge' : 24.00 (1 2 issues) 
Foreign Shipping Surcharge': 1 2.00 (6 issues) 

Z-SUS Disks, ordered individually: 

These are the disks that subscribers receive approxi- 
mately once a month. Order just the disk you want! Or 
put in a subscription to begin on any issue to receive that 
issue and the following 5 or 11 (depending on length of 
subscription you select). 

Price per issue (1 to 3 issues): $10.00 

Price per issue (4 to 9 issues)^: 9.00 

Price per issue (1 or more)^: 7.50 

Foreign Shipping Surcharge': 2.00 per disk 



Z3COM Package: 

A full set of executable (.COM) files supporting ZCPR3 
and the Z-System. The package consists of 456 files total- 
ing 1,564+k, as of January 1, 1991. It comes on six DSDD 
disks in a collection of libraries. The Z3COM Package con- 
tains earlier programs designed to run under ZCPR 3.0 
and 3.3 as well as the newest utilities supporting NZCOM 
and ZCPR 3.4. It includes some essential general CP/M 
programs such as ARK, UNARC, CRUNCH, UNCR and 
NULU as well. You will be amazed at the treasures to be 
found in this collection! 

Price: $36.00 

Foreign Shipping Surcharge': 4.00 

Z3HELP System: 

The Z3HELP System consists of a set of libraries con- 
taining on-line help for nearly all available Z-System pro- 
gram s and util ities. It is designed to work wi th LBRHELP . 
Examples are given to assist you in installing this compre- 
hensive system. Updates are published in each issue of 
the Z-SUS subscription disk. 

At the present time, the Z3HELP System contains well 
over 1 Megabyte of compressed files and is distributed on 
4 DSDD disks. This is one of our most popular packages. 

Price: $20.00 

Foreign Shipping Surcharge': 3.00 

TCJ Articles: 

A collection of articles written by Jay Sage, Bridger 
Mitchell and others relating to Z-System as printed in The 
Computer Journal. We encourage you to subscribe to 
TCJ, the only general circulation magazine offering strong 
support to CP/M and Z-System, and offer this collection 
to show the quality of articles. Distributed with permission 
on two DSDD disks. 

Price: $10.00 

Foreign Shipping Surcharge': 2.50 
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And the Best New Software Closer to You! 

And let us help guide the way. Z-SUS keeps Z-System 
users around the world updated on the newest public 
domain software--the heart, and soul of personal 
computing. 



Z-SUS Programmer's Pack: 

A comprehensive collection of tools for the Z-System 
programmer. This set of 8 DSDD disks includes all the 
official Z-System Libraries, as well as essential utilities, 
modules and routines which today's Z-System 
programmers and developers find most useful. Both 
Microsoft and SLR formats of the official REL files are in- 
cluded. (Note: source code for the Libraries is proprietary 
and could not be included). You receive complete 
documentation, on-line help and the full release LBR files 
for all included tools: ever)4hing needed to join the ranks 
of Z Programmers! 

Price: $48.00 

Foreign Shipping Surcharge^ 5.00 

Custom Order Disks: 

Need something from the past? If it is listed in 
ZFILEV.LST, then the Z-SUS Custom Order Disk service 
can get it for you! Best yet, the price isperdisk, not per file! 
Just be sure not to exceed your disk capacity. Order full 
release LBR files only. Sorry, no discounts on this labor 
intensive service. 
Price: $10.00 per disk 

Foreign Shipping Surcharge^ : 2.00 per disk 



Z-SUS Word Processing Toolkit: 

This package contains Z-System programs and utili- 
ties useful in text and word processing. Classics such 
as Carson Wilson's ZDE are included as are tools and 
tips for handling and printing text in its many forms. 
You even get a full-blown spelling checker! Over a 
megabj^e of software distributed on four disks. Special 
thanks to Carson Wilson, Gene Pizzetta and Lee Bra- 
dley for input to the selection of files for this package. 

Price: $20.00 

Foreign Shipping Surcharge^ 3.50 



A Note of Recognition: 

The many files that Z-SUS offers you are the result of 
thousands upon thousands of hours of effort on the part 
of hundreds of individuals. Each has donated his or her 
work to the public domain. It would be inappropriate to 
enjoy the fruits of their labor without expressing our 
gratitude. To all the folks who write for the Z-World, 
thank you! You are the very heart of Z-System. 



Ordering Information 
^Foreign Shipping Surcharge: Prices shown are for orders to the US, Canada and Mexico. All others must add 

shipping surcharge. Sorry, surcharge is not subject to discounts as it reflects actual costs we incur in processing 

your order. 
^Z-Node Sysop Discounts: Z-Node sysops receive a 50% discount from standard rates on all Z-SUS products 

except Custom Order Disks. Multiple-disk rates on individually ordered Z-SUS subscription disks and foreign 

shipping surcharge not subject to discount. 
Note to Amstrad Owners: Due to high cost of disks, a surcharge of $5 per disk must be imposed. This is waived if 

you supply your own formatted disks in either 48-tpi or 96-tpi formats. 
Formats Available: We support nearly all 5.25 inch CP/M formats, both 48-tpi and 96-tpi, as well as 8 inch. Please 

inquire regarding hard sectored formats. 
Method of Payment: Payment must be in US funds drawn on a US bank. 

V / 



The Computer Journal / #49 



A-3 



Z'SUS 

What's It About and 

Who's Behind All This, Anyway? 



The Z-System Software Update Service (Z-SUS) is a reincarnation of an 
old idea. Years ago, when the Z-World looked to Echelon for products 
and support, it was recognized that the fastest way to keep users up to 
date was through use of modems and remote access computer systems 
dedicated to the task. Thus was bom the network of Z-Nodes. 

But it was also recognized that not everyone had modems. And some 
who did lived in remote areas, or outside the United States. For these 
people, a simple call in to a Z-Node was not simple at all! At the least, it 
was prohibitively expensive. 

Echelon established a mail order service to keep such users updated. 
But that was then. In the interim. Echelon went the way of so many other 
companies: into the drink. Left behind was a world of Z-Users who still 
needed support. 

The Z-Nodes remain. In fact, should you have occassion to call the 
typical Z-Node, you will find the activity is greater than ever. However, 
the important task of supporting the remote and non-US user remained 
unresolved. 

In the summer of 1989, Chris McEwen, sysop of Socrates Z-Node 32, 
approached Jay Sage with the idea of reviving the update service. As the 
author of the last two versions of ZCPR, and a Z-Node sysop himself. Jay 
was very interested in the proposal. Both recognized the need but neither 
felt capable of handling the task of compiling the necessary software or 
editing the issues. For months it seemed the new Z-SUS would be still 



bom for lack of an editor. 

Meanwhile, Bill Tishey was busy on his own compiling lists of Z-Sys- 
tem software releases and meticulously preparing libraries of help (on- 
line documentation) files. It was decided that Bill's skills were needed for 
Z-SUS. The question was, would he be willing to take on the tremendous 
task? 

You have before you Bill's answer. Z-SUS today has a broader product 
list than ever before! Users from around the world rely on regular update 
disks and special packages provided through the system. You can, too. 

Who, again, makes up Z-SUS.' 

Jay Sage is the publisher and business agent. He handles your ac- 
count, accepts orders and keeps things on track. Jay operates Newton 
Centre Z-Node 3. 

Bill Tishey is the editor. He searches the world for the latest and 
greatest public domain software releases for Z-System. From these. Bill 
compiles the regular Z-SUS subscription disks, and the many special 
packages. Bill welcomes your ideas for new Z-SUS products. 

Chris McEwen handles production and distribution. Write to him 
regarding problems with disks. He also handles Z-SUS promotional 
efforts. If you know someone who needs our service, let Chris know. 
Chris operates Socrates Z-Node 32. 

Z-SUS exists to serve you! Let us know of any ways we can serve you 
better. 



Z-SUS Order Form 



Name 

Address 

City 

State /Province . 



Zip 



Computer Type 

Drive Type / Capacity 

Format Alternate 

Telephone 



Item Description 



Qty 



Total 



Z-Node Sysop Discount' 

Foreign Shipping Surcharge^ 

Order Total 
'Not Applicable to Subscription Disks ordered individually, or Custom Oder Disks 



^Applies to orders outside US, Canada and Mexico only 



For subscription orders: Which issue should we start your subscription on? 
Most Current Issue: Volume: /Issue: 



How are you paying for your order: 

Visa / MasterCard Account Number: 
Issuing Bank: 



Check: Money Order: 



Visa: 



MasterCard: 



/ 



/ 



/ 



Expires: / 



Signature: 



Payvnent must be in US Funds drawn on a US bank. 

Mail your order to: 

Sage Microsystems East 

1435 Centre Street 

Newton Centre, MA 02159-2469 USA 

Voice: (617) 965-3552 (Sunday - Thursday, 9:00 am - 1 1 :30 pm) 

Data: (617) 965-7259 (24-hr, 3/12/2400 bps, password=DDT) 
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LAN Basics 



By Wayne Sung 



For several issues we will be talking about local area net- 
works (LANs) in general and Ethernet specifically. Before 
diving in, I thought I would try to define some items com- 
monly used in LANs. Sometimes I forget that not everyone is 
in the networking business. 

The biggest difference between a LAN and a number of 
point-to-point connections is the sharing of the LAN by all 
devices connected to it. In contrast, each point-to-point con- 
nection is totally controlled by the owner of the port in- 
volved. 

This sharing means that only one station attached to the 
network may transmit a message at any given time. The rules 
that govern this process constitute an access method. The 
access method for Ethernet is called CSMA/CD (carrier sense 
multiple access with collision detect). 

The cabling that runs from one station to another is called 
the medium. This can be coax, twisted pair, or fiber. There 
are even some wireless LANs, using radio waves or infrared 
light. Ethernet started life as a coax medium but today runs 
on many different media. Twisted pair particularly is coming 
on strong. 

Local area networks tend to run at fairly high speeds com- 
pared to point-to-point transmission. This is not universally 
true, though. Apple's Localtalk runs at 230.4 Kb/s, compared 
to 10 Mb/s for Ethernet. However, this network signaling 
rate is not the most important factor in choosing a LAN. 
More on this in the next issue. 

Stations (typically computers) attach to the medium 
through transceivers. These are small boxes with connectors 
for the medium side and the computer side. In high-signal- 
ing-rate systems such as Ethernet these boxes are metal for 
shielding. Lower frequency systems, such as Localtalk, can 
use plastic cases. 

In Ethernet, transceivers attach to the coax in a number of 
ways. In thick Ethernet systems, it is possible to drill a hole in 
the coax (thick coax is an inch in diameter) and mount a tap. 
The transceiver mounts to the tap. 

In thin coax systems, the cable is usually cut and two BNC 
connectors are mounted on the cable ends. Then a T connec- 
tor allows the transceiver to be connected. 

The transceiver converts the separate input and output 
signals the computer uses to the single coax that all stations 
use. In Ethernet there is also a hardware collision detect func- 
tion in the transceiver. The transceiver cable which connects 
to the computer has pairs for transmit, receive, collision de- 
tect, and power. 



Wayne Sung has been working with microprocessor hardware and software for 
over ten years. His job involves pushing the limits of networking hardware in 
attempting to gain as much performance as possible. In the last three years he has 
developed the Gag-a-matic series of testers, which are meant to see if manufacturers 
meet their specs. 



Often the transceiver is built directly into the network con- 
troller that fits in the computer. This eliminates the trans- 
ceiver cable as well as the transceiver casing and allows sig- 
nificant price reduction. 

Local area networks are often characterized by topology, 
that is, the type of picture that results when the network is 
drawn schematically. Thus Ethernet is often called a bus to- 
pology LAN, because it tends to look like a straight line with 
stations coming off the line. Another common topology is the 
ring, used in IBM Token Ring and others. 

Note that this is a logical topology, and does not in any 
way dictate the physical topology. In running wire to connect 
the stations, a star shape (a central point with spokes radiat- 
ing from it) is the most common. This is because most build- 
ings already have ways to get wire from any room to a wir- 
ing closet. 

When using fiber it is not possible to tap the line the way 
coax is tapped. This is because light does not split in a fiber 
the way current splits in a wire. When using twisted pair the 
rules call for each transceiver to be connected to a repeater 
individually. Thus in these two cases a star wiring scheme 
naturally results. 

A LAN is best characterized as a switch which allows any 
attached station to send messages to any other. The format of 
the messages is very similar to a a piece of mail. There must 
be something to identify who sent the message and whom it 
is intended for. This is why these messages are often called 
packets. 

The contents of each packet are independent of the deliv- 
ery mechanism. Usually there is a hardware-generated 
checksum (CRC-32 in Ethernet) available for error-checking. 

In actual use the exact type of LAN is not all that impor- 
tant. Correctly built, any LAN works well. However, bad 
practices abound and the tone of the my articles in subse- 
quent issues of TCJ is a little cynical, because I have had to 
locate and fix many of these bad practices. 

Much of what I will have to say is based on experiences 
gathered while engineering the coNCert network in North 
Carolina. (coNCert stands for Communications for North 
Carolina Education, Research and Technology. This is a data 
and video network). 

I am primarily a hardware person, and as such am always 
on the lookout for measurement methods that can help me 
do my job. It is this search for test methods concerning LANs 
that led to the design of the first Gag-a-matic. But first some 
history. 

In 1985, the job of building a state- 
wide high speed data network began in 
earnest. The goal was to go to Tl data 
rates (1.5 Mb/s) across cities as soon as 
possible and go as high as possible af- 
ter that. This was based on the design 
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of the microwave system used for inter-city communications. 
These were built for multiple Tls with a total capacity as 
high as 45 Mb/s. 

At first Ethernet bridges were used to join the various 
campuses that were part of the network. These first ones 
couldn't actually run at a full Tl. Over a year later, more 
bridges were acquired which could use a whole Tl. 

When the campuses were first linked, there were perhaps 
250 computers involved. At first the growth was not stagger- 
ing. Even two years after the initial links were established 
there were maybe 500 computers connected. Then things be- 
gan to take off. 

As the price of workstations began to decline, connections 
happened at a much more rapid pace. Today, just over four 
years later, there are more than 3,000 computers connected. 
The drastic increase in traffic volume uncovered some weak- 
nesses in the network. 

One of the things that showed up was that there was so 
much broadcasting and multicasting going on that macfiines 
were literally spending all their time processing these and not 
doing any useful work. This will be discussed in more detail 
in the next issue. 

Even though we were trying to control this problem by 
deliberately cutting off some types of broadcasts and multi- 
casts, it turns out they tend to increase geometrically with the 
number of machines connected, and we knew we had to go 
to a different way of connecting the campuses, namely rout- 
ers. More on these in two issues. 

Back to the subject of testing. At first there was a commer- 
cial LAN tester available to me, but I never liked it because it 
was not at all easy to set up, and often by the time I could get 
it running the problem had gone away. Thus I decided to see 
if I could do better developing my own test devices. 

In most commercial testers, you get a packets-per-second 
reading. However, they almost always average this over a 
one second period. In an Ethernet, packets with minimum 
spacing between them and packets evenly spaced are very 
different loads, even if the total packets are the same. Closely 
spaced packets are much more difficult to receive. 

In an interrupt-driven receiving device, there will be a 
minimum response time. If the peak packet rate exceeds 
what this response time allows, then packets will be lost. 
Even if the receiving device is not interrupt-driven, you 
might still lose packets because there aren't enough cycles to 
process packets at such a high rate. 

You also cannot arbitrarily decrease the averaging interval 
in the measurement device, because the same number of in- 
structions will need to run more often. This will cause the 
device to run out of cycles. As it turns out, this commercial 
device I had, even though represented as a full speed device, 
ran out of cycles anyway. 

Rather than trying to build a faster software device, I 
looked at what I was trying to measure. It turns out to be the 
energy in the line. By integrating the voltage pulses on the 
line, I could get a much better picture of bursts. While trying 
different ways to make this measurement I tried putting an 
audio VU meter across the line. 

This type of meter normally did the type of integrating I 
was looking for. In audio work you have the same problem 
to solve. A short loud sound is perceived differently by the 
human ear than a continuous sound. The VU meter compen- 
sates for these differences. I still use this meter for quick 
checks. 

As the speed of bridges and routers improved rather 
quickly, we found that normal traffic could no longer outrun 
these units. At the same time, the advertisements (and some- 



times even the specifications!) showed such high processing 
rates that it seems you could never overload them. Thus the 
Gag-a-matic 1 was born. 

A friend of mine in the music business likes to turn ampli- 
fiers on full and hear what they sound like when driven to 
distortion. He would always say, "Let's gag it." Since I was 
doing the same thing to networking devices, I named my 
testers in honor of him. 

In essence a Gag-a-matic tries to deliver Ethernet packets 
at as high a rate as possible. The first such was a Multibus 
Ethernet controller. 

It wasn't long before we were testing Ethernet devices for 
throughput. Gag-a-matic 1 puts out over 14,700 packets per 
second (at a 64 byte packet size the Ethernet limit is 14,880). 
The packets themselves are limited to one or two different 
types, but when tfus unit was built we were using only 
bridges, and we didn't need too many packet types. 

Few devices have succeeded in passing this stream. We 
quickly found out that our commercial tester simply could 
not keep up. By slowing the stream down we found that the 
tester started losing detail at as little as 3% load and beyond 
10% was hopeless. 

It turned out that the Ethernet board in the tester has 
about 700k of memory, and as long as that wasn't exhausted 
the packets coming in could be captured. Once this memory 
was used up, packets had to be moved to host memory. It 
took several packet times to move one packet, thus much 
data would be lost. 

Since I only wanted packets-per-second, it occurred to me 
to put a frequency counter on the carrier detect pin of an 
Ethernet device. This is how Gag-a-matics are "calibrated", 
since if only one device is talking there are no collisions and 
the frequency counter produces accurate readings. 

I now have Gag-a-matic IV (subtitled "Just when you 
thought it was safe to go onto the network again"). This is 
not the fourth unit but rather is a four-headed device, which 
can generate four different packet streams at the same time 
with enough CPU capability to calculate protocol-related 
data in the packets. Salesmen are beginning to hate us. 

Interestingly enough, while Gl is a 10 MHz 68010, G4 
uses four 33 MHz 68020 processors but actually is slightly 
slower ~ it only does about 14,600 packets per second per 
stream. This is due mostly to the different Ethernet devices, 
but G4 is so much easier to load that I could actually bear to 
write a "user interface" to it. 

On the other hand, Gl has no more than a debug monitor, 
and I have to load S-records into it, so I tended to keep the 
test programs as small as possible. G4 has ways of loading 
from Ethernet. 

Nonetheless, I had to kick out the resident operating sys- 
tem when 1 started the Ethernet device. Without directly con- 
trolling the chip, the speed was maybe 1,500 packets per sec- 
ond. I was shown how to bypass most of the operating sys- 
tem, but even calling the Ethernet driver directly only got me 
up to 4,000 packets per second. 

1 wanted G4 because we finally convinced the manufac- 
turer of the microwave system to give us a way to use the 
whole 45 Mb/s as one stream rather than 28 Tl's. Thus I 
wanted to generate the equivalent of four full Ethernets of 
traffic. The devices that can switch that much traffic are a 
little hard to get as yet. 

These articles are not meant to show how to build a LAN. 
Construction practices are usually supplied by component 
vendors, and should be followed closely. In the next issue we 
will examine some not-so-obvious things that might prevent 
you from getting maximum performance from your LAN.# 
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The Z-System Corner 

Putting the NZCOM Virtual BIOS to Work 



By Jay Sage 



For this issue we are going to look once more at ways to 
use the NZCOM virtual BIOS. Ten issues back, in TCJ #39, 1 
talked about how one can take advantage of NZCOM's in- 
credible ability to change the BIOS, statically and dynami- 
cally, without requiring any source code for the computer's 
real BIOS. In that column I described how Cam Cotrill, one 
of the authors of the Z-System DOS (ZDOS), used the 
NZCOM virtual BIOS to overcome problems experienced 
with ZDOS on computers whose real BIOS failed to preserve 
the Z80 index £tnd/or alternate registers across BIOS function 
calls, as is required for ZDOS. To Cam's code, I added my 
own enhancement to implement the Z-System environment's 
drive vector. 

I had hoped that those two examples would inspire others 
to apply this technique to a wide range of problems, but so 
far nothing has appeared. It's not for lack of a need, how- 
ever, for I have seen on Z-Nodes quite a few discussions of 
issues that could be hcindled quite nicely in this way. Ever the 
optimist, I will try a few more examples. Two of the ex- 
amples will essentially be the solutions to problems asked 
about recently in messages posted on Z-Nodes. 

The starting point will be the modified NZCOM BIOS that 
I discussed in the earlier TCJ column. The main parts of the 
code are shown in Listing 1. Several interesting features are 
worth pointing out before we proceed to our new modifica- 
tions. 

The beginning of the code has the material required for 
the generalized loading concept developed by Bridger Mitch- 
ell and described in detail in TCJ issue #33 (if you don't have 
all these back issues, you would do well to pick them up). 
The NAME statement embeds an ID into the REL object code. 
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The NZCOM.COM and JETLDR.COM loaders use this ID to 
recognize the function of a module they have been asked to 
load so they can figure out its proper load address. The 
COMMON statements allow any addresses in the Z-System 
to be installed into the code by the loader at load time. This is 
the beauty of Bridger's concept: a single binary file can be 
used in many different systems. 

The next section of the code must adhere to a rigidly de- 
fined format. First comes the table of jump vectors as re- 
quired in the CP/M-2.2 specifications. With the exception of 
the cold and warm boot routines, these jumps would nor- 
mally go directly to the real BIOS. Since we want to intercept 
this code and enhance its functions, we vector to other loca- 
tions in the virtual BIOS code. Note that the jump vector 
table has room for 13 extra custom BIOS functions that might 
be implemented in the user's system. 

The block of jump vectors is followed by some special 
data for NZCOM. First there is an ID string that can be used 
by programs to determine if an NZCOM version of Z-System 
is currently running. Then there is a data byte with the num- 
ber of the user area where the command processor file is 
stored. In an NZCOM system, the command processor is 
loaded from a file and not from the system tracks of the disk. 
Finally, there is the space for the file control block for the 
CCP file. Then comes the replacement warm boot code that 
loads this file. 

This is an area where changes would be made in a multi- 
user system (a number of such systems are around, including 
some manufactured by Televideo). Imagine that there are 
two terminals running on the system and each user wants to 
run a different configuration of NZCOM. Clearly, they can't 

both use the same NZCOM.CCP file. 

Therefore, each user has to be set up 
with a different name or user area for 
the CCP file. One place this change 
would have to be made is in the virtual 
BIOS code. I am not going to say any 
more on this subject, but I hope that 
some day we will get a TCJ submis- 
sion dealing with the issues of imple- 
menting Z-System on a multi-user sys- 
tem. 

Now we finally come to the internal 
BIOS function routines, such as 
ICONST and ICONIN. All of these en- 
try points have code that loads the A 
register with the address offset in the 
jump table of the real BIOS and then 
calls the routine DOBIOS, whose func- 
tion was described in detail in my col- 
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umn in issue #39. Briefly, DOBIOS saves all the alternate and 
index registers, calls the real BIOS function, restores the reg- 
isters, and then returns to the calling program. 

If we want to incorporate additional functionality, this is 
the place for it. The code in Listing 1 includes the enhance- 
ment to the select-disk code to make it check the drive vector 
and return an error code if the drive is not enabled. This 
code, too, was discussed in detail in issue #39. 

Changing the Logical Drive Assignments 

There are times when you may not like the way the manu- 



facturer of your computer has assigned the logical drives 
(those things you know as A:, B:, and so on). On my Telev- 
ideo 803H, the hard drive has the two partitions A: and B:, 
while the floppy is C:. As an example, I have implemented a 
special NZCOM BIOS that swaps drives B: and C:, so that the 
floppy can be referenced as B: and the second hard disk par- 
tition as C:. I'm not sure why one would want to do this, but 
there might be reasons. 

The ISELDK routine with the additional code is shown in 
Listing 2. The code is pretty simple. When the SELDSK BIOS 
function is invoked, the requested drive is passed in the C 



Liating 1 . The modified NZCOM BIOS source code that protects 
the Z80 alternate and index registers and that checks the 
ENV drive vector when selecting a disk. 

; Program: ZSNZBIO 

; Author: Joe Wright / Cameron W. Cotrlll 

; Version: 1.2 

; Date: 26 January 1989 

; Derivation: NZBIO.Z80 version 1.5 

; This version has been modified to check the drive vector 
; in the disk select routine. 

; ... copyright notice and comments 

NAME ('BI0Z12') 

COMMON / ENV / 



; NZCOM needs 'BIO' as first 
; . .three characters 



Z3ENV: 






CCP 


EQU 


Z3ENV+3FH 


DOS 


EQU 


Z3ENV+42H 


DRVEC 


EQU 


Z3ENV+34H 




COMMON 


/ CBIO / 


CBIOS: 







; Address of ENV module 
; Where CCP address stored 
; Where DOS address stored 
; Drive vector address 



; Address of real BIOS 
CSEG 

; ... section with equates amitted 

; Beginning of NZBIO. The header structure is absolutely 
; crucial to the correct operation of NZ-COM. 
— > DO NOT CHANGE IT <-- 



START: 


JP 


BOOT 




; Cold boot 


WBOOTE: 


JP 


WBOOT 




; Warm boot 




JP 


CONST 




; Console status 




JP 


CONIN 
rest of jump 


table 


; Console input 




JP 


IWRITE 




; Write 




JP 


LISTST 




; List status 




JP 


ISECTR 




; Sector translation 




DS 


(30-17)*3 




; Room for 13 extra jun^s 


SIGN: 


DB 


'NZ-COM' 




; ID for NZCOM BIOS 


USER: 


DB 







; User area for CCP file 


ZCFCB: 


DB 
DS 


1, 'NZCOM 
17 


CCP' 


0,0,0,0 



...auxiliary jumps for lOP (omitted) 

END OF HEADER 

The following code is free-form and may be moved around 

. . . coldboot code ( omitted ) 

Warm Boot Entry 

WBOOT: 

; . . . seme of code omitted 

LD DE, (USER) ; Log into user area where 

liD C,GSUSR ; NZCOM. CCP ia kept 

CALL NZDOS 

XOR A 

LD (ZCFCB+32),A ; Clear current record 



LD C,OPENF 
CALL NZFIL 
LD HL,(CCP) 



; Open NZCOM. CCP 
; Load it at CCP 



; Read NZCOM. CCP to (CCP) until end of file (code omitted) 

; ... BDOS service routines ( omitted ) 

; The following calls build a shell euround BIOS calls and 
; preserve the IX, lY, and alternate registers as required 
; by ZSDOS and ZDDOS ( and common sense ) . 



ICONST: 


LD 


A, 6 




JR 


DOBIOS 


ICONIN: 


LD 


A, 9 




JR 


DOBIOS 



; ... similar code for other functions omitted 
ISECTR: LD A, 48 



: LD 


HL, CBIOS 


ADD 


A,L 


LD 


L,A 


EXX 




LD 


(HLP),HL 


LD 


(DEP),DE 


LD 


(BCP),BC 


LD 


(IXREG),IX 


LD 


(iyREG),lY 


EXX 




EX 


AF,AF' 


PUSH 


AF 


EX 


AF,AF' 


CALL 


JPHL 


EXX 




LD 


HL,{HLP) 


LD 


DE, (DEP) 


LD 


BC,(BCP) 


LD 


IX,(IXREG) 


LD 


lY, (lYREG) 


EXX 




EX 


AF,AF' 


POP 


AF 


EX 


AF,AF' 


RET 





; Never a carry frccn this 
; Swap to alternate reg ' s 
; Save alternate registers 



; Save index registers 

; Swap back 

; Save alternate PSW also 



Do BIOS call 

Swap to alternates 

Restore them 



; Restore index registers 

; Restore alternate PSW 
; Return to caller 



; Special routines are coded here. 



LD 


HL, (DRVEC) 


LD 


A, 16 


SUB 


C 


LD 


B,A 


ADD 


HL,HL 


DJNZ 


ISELDSKl 


LD 


HL,0 


RET 


NC 


LD 


A, 27 


JR 


DOBIOS 



Get drive vector 
Get 16-drive into B 



; Value for invalid drive 
; Return if invalid drive 
: Otherwise, use CBIOS 



; ... area for saving register contents (not shown) 
; End of NZBIO 
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register. The code checks sequentially for values of 2 (C:) and 
1 (B:), and it changes the value in C to 1 and 2 respectively. If 
the value is neither 1 nor 2, then the value is left unchanged. 
Finally, the BIOS routine is called. Thus, virtual BIOS tricks 
the real BIOS, which still knows the drives by their original 
names. 

Once this code has been entered, say under the name 
SWAPBC.Z80, then it is assembled to a REL file (Z80ASM 
SWAPBC/R in the case of the SLR assembler). If you wish, 
the file can be renamed from SWAPBC.REL to SWAPBC.ZRL 
just to make it clear that it adheres to the ZRL standard. The 
loaders don't care which name is used. Now you just enter 
the command JETLDR SWAPBC.ZRL and, presto, you have a 
new BIOS with the drive designations reversed. 

Some cautions are in order. Drive references that occur 
within the real BIOS will still use the same physical units and 
will not know about the swap. External routines that call the 
BIOS or DOS will see the drives as swapped. Thus swapping 
the A: drive (assuming that is where NZCOM.CCP is loaded 
from) will cause the CCP file not to be found. I just tried 
modifying the code in the listing so that it swapped A: and 
B:. I also changed the number 1 in the first byte of the 
NZCOM.CCP file control block to a 2. Now the CCP file will 
be loaded from the B: drive, which used to be the A: drive. It 
worked just fine! 

In this example, the drives are relogged automatically by 
the loader. If you try writing a more sophisticated BIOS that 
has a swap table in it that you intend to change later using a 
utility, just make sure that the utility forces a relogging of the 
swapped drives (or all drives) after the swap has been imple- 
mented. 



Listing 2. Modified select-disk 


BIOS routine that also swaps 


logical drives 


B and C. 




ISELDK: LD 


HL, (DRVEC) 


; Get drive vector 


LD 


A, 16 


; Get 16-drlve into B 


SUB 


C 




LD 


B,A 




ISELDSKl : 






ADD 


HL,HL 




DJNZ 


ISELDSKl 




LD 


HL,0 


; Value for Invalid drive 


RET 


NC 


; Return if invalid drive 


LD 


A,C 


; Get disk requested 


CP 


2 


; See if it's C: 


JR 


NZ , ISELDSK2 


; Skip if not 


LD 


C,l 


; If so, change to B: 


ISELDSK2 : 






CP 


1 


; See if it's B: 


JR 


NZ , ISELDSK3 


; Skip if not 


LD 


C,2 


; If so, change to C: 


ISELDSK3 : 






LD 


A, 27 


; Now log in drive 


JR 


DOBIOS 





Listing 


3. Modified list output 


routine. It checks the 1 


printer 


width 


byte in the environment. If the value is 0, | 


printer output 


is disabled by s 


in^ily returning without 1 


calling 


the real BIOS list output routine. 


POOL 


EOU 


Z3ENV + 37H 


; Address of width data 


ILIST: 


LD 


A, (PCOL) 


; See if printer width is 




OR 


A 


; . . set to 




RET 


Z 


; If so, just return 




LD 


A, 15 


; Else, call BIOS 




JR 


DOBIOS 





Disabling the LiST Device 

I think it was our editor Chris McEwen who raised this 
issue with me. As I recall, he was unable to use a particular 
utility on his Z-Node because it had a function— not disabled 
when the wheel byte was off— that engaged the printer. 

I had faced a similar problem myself. 1 have no printer 
attached to most of my computers, and occasionally I would 
accidentally hit a key that would initiate a printing operation. 
On some of the computers this meant instant crash! The BIOS 
would wait forever for the printer to signal that it was ready, 
and if I didn't want to wait that long, I had to hit the little red 
button, losing all my work. 

My simple solution to this was to go into the BIOS and 
replace the jump instruction for the LIST function with a 
simple RET. Boy could that printer print fast! A little POKE 
instruction in my startup alias could handle this for me very 
nicely. 

When Chris presented his problem, I told him he could 
use the BIOS in his NZCOM to take care of things. Just make 
up two versions of the BIOS, one normal version and one 
with the list routine RET'd out. Then just use NZCOM or 
JETLDR to install the one needed. 

The code shown in Listing 3 is a more elegant solution. It 
looks at the printer configuration data stored in the environ- 
ment. If the width is set to zero, then the print output is 
disabled. Otherwise it functions normally. As you see, the 
code is short and sweet. 

Console Input/Output Enhancements 

George Worley asked on Z-Node Central for a suggestion 
as to how he could get his system to send some escape se- 
quences to his terminal whenever he pressed certain keys. 
Again, the NZCOM BIOS can solve the problem. 

I originally wrote a virtual BIOS that would remap some 
keys on the keyboard. I make it interchange the 'a' and 'b' 
keys— not likely to be very useful, but it illustrated the point. 
I'm not going to show you that code; it is quite similar to the 
code for swapping drives except for one detail that will be 
covered in the example I will present. 

The interesting thing about George's problem is that 
something going on in the console input routine is supposed 
to initiate an activity with the console output routine. The 
notion of mixing up the BIOS functions caught my interest. I 
decided to write a BIOS that would change the cursor on my 
Televideo terminal to a blinking block when I typed a tilde 
and back to a blinking underline when I typed a back apos- 
trophe. See Listing 4 for the result. 

The thing that is different here from the earlier examples 
with the SELDSK function is that in those cases the action 
was taken with input data, before the function was called. 
Here we must take action on data returned by the function, 
after the function has executed. Instead of jumping to 
DOBIOS, we call it and then continue with our code on re- 
turn from it. 

Once we have the character returned by CONIN, we 
check to see if it is either of our trigger characters. If not, we 
just return to the calling program with the character. If we do 
detect one of the trigger characters, then we send a string of 
characters to the screen using the CONOUT function. When 
that operation is complete, we then get the typed character 
back into its proper register and return. 

I hope these examples will get you thinking about new 
ways to use the virtual BIOS. I have shown only very simple 
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code. NZCOM allows one to declare as much space as one 
wants for a virtual BIOS, and someday I would like to see 
someone write a version of BYE that can be loaded as a vir- 
tual BIOS. 

Z-System for MS-DOS 

I'd like to finish with a brief announcement. I had origi- 
nally hoped to discuss this in more detail, but there just is not 
time or space, so I will leave it for the next issue. But I do 
want you to know about it now. 

I'm sure I'm not the only Z-System user who also uses 
MS-DOS computers and finds DOS's primitiveness annoying 
and frustrating. Well, the new version 2 release of PCED 
(Professional Command line EDitor) is a DOS enhancement 
product that comes as close as any 1 have yet found to bring- 
ing the features we love in Z-System to MS-DOS. This is not 
entirely accidental, as I made the author aware of our Z- 
System work. As a result, PCED gives one most of the func- 
tionality of LSH and ARUNZ: full command history, both 
line and screen oriented, with editing and searching; multiple 
commands on a line; command scripts with advanced pa- 
rameter parsing. There are some Z-System features that 
PCED does not add to DOS, but there are also many very 
powerful features it does bring that are probably only pos- 
sible with the larger memory available on a DOS machine. 

As is my wont with products like this that I use myself 
and really like, I got Sage Microsystems East to add it to the 
product line. PCED is now available at a very attractive price 
of only $50. I'll try to tell you more about it next time. • 



Listing 4. Modified CONIN routine. When particular 
characters are typed at the keyboard, escape sequences are 
sent to the screen. In this particular exan^le, typing a 
tilde causes the escape sequence to select a blinking block 
cursor to be sent to the screen, while typing a back 
apostrophe sets the cursor to a blinking underline (for my 
Televideo terminal). Thanks to Howard Goldstein for this 
improvement to my original code. 



A, 9 
DOBIOS 



Z , SEQl 



ICONIN: ID 

CALL 

CP 

JR 

CP 

RET 



Back apostrophe was typed 
PUSH AF 
LD A, '3' 
JR SEQ 



SEQl: 



SEQ: 



PUSH 
LD 

LD 

PUSH 

LD 

CALL 

LD 

CALL 

LD 

CALL 

POP 

POP 

RET 



AF 
A, '1' 

(POKE+1) ,A 

BC 

C,1BH 

ICONOT 

C, ' . ' 

ICONOT 

C,$-$ 

ICONOT 

BC 

AF 



; Perform the BIOS call 

If tilde, send out 

. . sequence 1 

If not back apostrophe, 

..return to calling 

. - program 

; Save input character 



; Save input character 

; Poke in final character 

; Send escape to screen 

; Send period to screen 

; Filled in from above 

; Send last char to screen 

; Get input character back 



continued from page 37 
guages, after all! 



Get Your Feet Wet 

No one ever learned how to swim without going into the 
water. Get a public domain program that includes source 
code. Use your assembler to reassemble/ link it, and then 
satisfy yourself that the resulting COM file is the same as the 
original one. This is not an exercise in futility! It gets you 
familiar with the mechanics of your assembler and linker, so 
you can think more about programming and less about oper- 
ating the assembler. 

While you are experimenting with small programs, look 
forward to the next phase by reading the excellent articles by 
Bender (reference 4), and the tutorial by Meyer (reference 6). 
Your experimental program should be a standard .COM file, 
not something more exotic. Assemblers, linkers, and 
MLOAD (or the newer MYLOAD) are designed to produce 
.COM files when no other forms are specified. So your code 
will begin at address OlOOH. The last instruction performed 
by your experimental program must return control to the 
operating system if you expect to continue use of your com- 
puter without resorting to a cold boot restart! The safe 
method is to make the final instruction a "JP OOOOH", which 
causes a warm boot followed by return to the Command 
Processor. 

If you need help, talk to your nearest AL programmer. Is 
there a subject you would like to see in more detail in the 
pages of TCJ? Tell the author about it, or write to the editor. 
[Ed Note: This is good material for ttie Reader-to-Reac/er column] The 
author can be reached via modem at (213) 670-9465, Z-Node 



#2 (Z-Node Central). 

What ever happened to John Poplett? He soon quit techru- 
cal writing and began programming professionally. He 
learned C, then learned assembly language for the VAX and 
for the 80x86 series of CPUs. The last time I heard from him 
he had tackled OCCAM, the assembly language for parallel 
processing transputers, and was busy with a C compiler for 
parallel processing.© 

References: 

(1) Z80-CPU Technical Manual, ZIlog, Inc., Campbell, CA 
(408)370-8016 

(2) Hitachi HD641 80 8-bit High Integration CMOS Microprocessor 
Data Book, Hitactii America, Ltd., San Jose, CA (800) 448-2244 

(3) Bruce Morgen, "REL-Style Assembly Language for CP/M" 
TCJ, Number 35, Nov 1 988, "Part 1 : Choose Your Weapons" 
TCJ, Number 36, Jan 1989, "Part 2: Getting started" 

(4) Andrew Bender, "Relocating Assemblers and Linkage Editors" 
Microsystems, Vol 4 No 9, Sept. 1 983, page 86 
Microsystems, Vol 4 No 10, Oct. 1983, page 114 
Microsystems, Vol 5 No 1 , Jan. 1984, page 120 

(5) Dennis N. Quinn, "Structured Programming witti M80" 
Micro/Systems Journal, Vol. 1 No. 3, Jul/Aug 1985, page 26 

(6) Eric Meyer, Introduction to Assembly Language Programming (A 
1 chiapter tutorial available in disk file form under the name 
"MEYERTUT.LBR" available on Z-Node #2) 

(7) Rodney Zaks, Programming theZSO, Sybex, 1979 
ISBN 0-89588-01 3-X 

(8) Kattie Spracklen, Z-80 and 8080 Assembly Language 
Programming, Hayden Book Co., Inc., 1979 ISBN 0-8104-5167-0 
LCCC No. 79-65355 

(9) William Wickes, Logic Design With Integrated Circuits, Jotin Wiley 
& Sons, Inc, 1968 LCCC No. 68-21185 

(10) 8080 Assembly Language Programmers Manual, Intel Corp., 
Cupertino, CA. Intel ref. number 98-004C (1976) 



28 



The Computer Journal / #49 



PMATE / ZMATE Macros 

2. Terminology and Utility Subroutines 

By Clif Kinne 



Notations for This Column 

A Shorthand for Macro Names 

In our first column we had two macros, which we named, 
'D' and "^D', and referred to them, as such,- enclosed in 
single quotation marks. It bothers me that we also use quotes 
around single characters for purposes other than to signify a 
macro name. We could get around that by always saying, for 
example, "the macro 'D'". However, if we agree, we can 
adopt an even more concise and more nearly unique short- 
hand name, which is the macro call itself,- .D in our example. 

The only conflict I can think of is that of the buffer calls, .0 
through .9, with the corresponding decimal fractions. So, un- 
til I am persuaded otherwise, I shall use .D as shorthand for: 
"the macro whose name is 'D"'. As a corollary, I propose to 
use .(n) as shorthand for: "the macro represented by the 
character whose ASCII number is n". This will allow us to 
identify macros where n = 128.. 255, as well as giving us alter- 
natives for control characters and other awkward situations. 

Radix Considerations in the iUlacro Listings 

For ease of reading, any numbers in the source code list- 
ings for the macros will be in decimal,- base 10. When clarity 
is enhanced by using an ASCII representation of the number, 
that will be done; e.g., for 'insert a semicolon' ";I is clearer 
than 591, which might require consulting an ASCII table. On 
the other hand, 75QX expresses what you are doing much 
more clearly than "KQX 

However, if you ever expect to be working in hex (or 
octal?) as Jay does on occasion, he cannot urge you too 
strongly to use radix-invariant number representation. That 
means an expression in one or more ASCII characters for 
numbers greater than 9 (7 for octal). For example, to move 
down 150 lines, the following two command lines are 
equivalent: 



avoid that, I shall use 13QX in this column, but, for radix 
invariance, you should convert it to 



(3) 
(4) 



'M-"«QX, 
'4/4QX 



for example, or 
to save a byte. 



In these columns I am also going to avoid the radix invari- 
ant form for the ASCII number of the SPACE character. In 
printed text it is hard to be sure whether a space is a space. I 
shall use 32 instead for that reason. 

Incidentally, if you ever want to change all decimal num- 
bers to hex, they can be found very easily using the .D macro 
presented in our first column. If you have .D in your permacs 
by now, get the permanent macros into an empty buffer with 
QMG, go to the top, and repeatedly execute 



(5) 



[.Dei>9] 



It should stop at every number greater than 9: an unantici- 
pated and unorthodox use for our first macro. 

MATE vs. PCMATE vs. ZMATE 

This is another area where vje shall have to keep clear 
what we are talking about. First, I propose that we recognize 
the three categories, rather than just "8-bit" and "16-bit" sys- 
tems. I suggest the above names as identifiers. I left the P off 
PMATE, to minimize confusion with PCMATE. We can then 
use PMATE as a generic term for all three. 

The differences in macros written for the three systems are 
slight, and we hope it will rarely be necessary to list a macro 
for more than one. As long as we keep aware of the differ- 
ences (see Table 1.) we should be all right. 

1 do not propose anything like an exhaustive discussion of 
these differences at this juncture, but let me cite a few conse- 
quences of these differences that bear on macros. As always, 
we shall appreciate your advising us of additions or correc- 
tions that should be made to this table. 



(1) 
(2) 



150L 
' ■K*2L 



(with base 10 radix) 
{with any radix > 2 ) 



This is no problem except for 13 and 32, the CR and 
SPACE characters. It is disturbing to have a macro insert a 
new line when you want it to say " '^MQX, for example. To 



Clif Kinne is a retired computer designer. He cut his teeth on vacuum tube and 
acoustic delay line machines in the fifties, made the transition to transistors and 
magnetic cores in the sixties, left the field to his children in the seventies, and tried, 
vainly, to catch back up with them in the eighties. He can be reached by voice at 617- 
444-9055, or via a message on Jay's BBS, 617-965-7259. His address is 159 Dedham 
Ave., Needham, MA 02192 



1. Numeric variables. 

With judicious use of the 100 variables available in 
PCMATE it should rarely, if ever, be necessary to save vari- 
ables on the stack. If that turns out to be true, the extra byte 
entailed in setting and referencing variables 10-99 may be a 
small price to pay. 

If you use the single-digit numbers, 

0..9, in PCMate, you will have to be 
careful. If the following command 
starts with a digit, separate the two, 
preferably with an ESCAPE. Otherwise 
PCMATE will read them as a 2-digit 
variable. 
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2. Preloaded variables. 

This has caused me some tergiversation. First I made the 
autoexec macro save @0, @1, and @2 in V90, V91, and V92, so 
I could save the extra byte most of the time. Then I found I 
was adding an escape, or a leading 0, to avoid the 2-digit 
syndrome. Furthermore, I was apprehensive that PCMATE 
might be doing something with V3..V9 sometime. So I 
switched to using V10..V99 exclusively. 

Having done that, however, I find that I am disturbed by 
how much I lengthen a macro when I translate it from MATE 
to PCMATE, often by a dozen or two bytes. And I feel a lot 
easier about the risk of some other use of variables by 
PCMATE. 

Now that I am writing this column, I am going to reverse 
myself again, except that I shall save @0, @1, & (32 on the 
stack instead of in V90, 91, & 92. That will help my macros to 
be usable in all three PMATES. I shall also find out some- 
thing about how often I am inadvertently losing the stack by 
aborting out of macros. 

Readers who only work in PCMATE should feel free to 
take advantage of the 90 extra variables. 

3. Support of B@SE, B@3C, B@6M, et cetera 

Fortunately, two of the three PMATEs support this. For 
one thing, this command makes it easier to use buffers with- 
out destroying their contents. We saw an example of that in 
the first of these columns last issue. For MATE, which does 
not support it, there are ways to guard against loss, and we 
shall offer macros to help in this. One, the Buffer Test, .'^B, is 
included as one of the utility macros in Listing 1. 1 am going 
to interrupt this rambling here to discuss utility subroutines 
in general, and my own most used utilities in particular, as 
prelude to further remarks. 

Macros for This Issue: Utility Subroutines 

Macros for Single-character User Input. 

See Listing 1 

1 believe it was a good three years before 1 gave any 
thought to utility subroutines. When I began to get "NOT 
ENOUGH ROOM IN PERMANENT MACRO AREA" fairly 
often, I began to look for ways to get more room without 
adding another allocation block to the size of MATE itself. 
So, I thought I would look through the permacs for repeated 
strings and see what could be done. Sure enough. About the 
worst repeater was the upper/ lower case-independent test 
for the key struck in response to a command-line question: 

(6) SK=' 'SI (8K=' 's) (13 bytes) 

where 'S' stands for any upper case letter. This can be short- 
ened to 



(7) 
(8) 



8K&95=' 'S 
iKS." ="S 



or its radix-invariant forro: 
( 8 bytes ) . 



The drawback with these latter two is that they cannot be 
used if admissible answers to the questions asked include 
digits or other characters with ASCII numbers between 32 
and 64. 1 had not given this much thought until I got PCMate 
early this year and found macros that came with it using the 
test: 



Sure enough: 'ORing' a byte with 32 (0010 0000 bin.) sets 
bit 5, converts upper case letters to lower case, and moves 
control characters up by 32 ASCII. But the digits and others 
have bit 5 set already, so are unaffected. 

On the other hand, ANDing a byte with 95 (0101 1111), as 
in (8) above, resets bit 5 (as well as bit 7), thereby corrupting 
the digits (and adjacent characters) to control characters. So I 
am converting to PCMate's form of the test, and am listing 
here subroutines based on that form. 



Listing 1. Macros for single character user input. 

X'A ;Answer. 15 bytes 

FUNCTIONAL SPECIFICATION: ORs the byte in «K with 
bit 5, converting upper case responses to lower. 
Ccmparea this with the argument preceding the 
call. IF equal, returns with TRUE on the stack. 
ELSE returns with FALSE on the stack. 



USAGE: 



Typical Call: "s.*A8S 



(9) 



8K132= 



; LIMITATIONS: The calling argument, ' 's , 
; cannot be a control character. 

@K132 ;IF the character typed converted to lower case 1 

= ;is equal to 2 

(8A132) ;the calling argiiment converted to lower case, 3 

, ; THEN push TRUE on the stack, ELSE push FALSE. 4 

;Ccn^act form: «K132=(8A132 ) , 

'X'Y ;Yes. 4 bytes 

; FUNCTIONAL SPECIFICATION: IF ''Y'' or ' 'y' ' is typed, 
; returns with TRUE on the stack; ELSE with FALSE. 

; SUBROUTINES USED: .'A, 'Answer' subroutine 
; USAGE: Typical Call: .'YSS 

''Y.^A; Invoke the Answer macro with ' 'Y as the argument. 

"X'C ;Confirm 50 bytes 

; FUNCTIONAL SPECIFICATION: Asks if okay to delete 
; or overwrite. IF Y is typed, returns with TRUE 

; on the stack; ELSE with FALSE. 

; SUBROUTINES USED: ."Y, 'Yes' subroutine 
; USAGE: Typical Call: ."CSS 

GOkay to delete or overwrite7S ;Ask the question. 1 
."Y ; Invoke the . *Y macro. 2 

B ; Buffer test. 16 bytes 

FUNCTIONAL SPECIFICATION; Tests whether current 

buffer is empty. IF so, returns with TRUE on 
the stack. ELSE asks if okay to delete buffer. 
IF Y, returns with TRUE on the stack; 
ELSE with FALSE. 

SUBROUTINES USED: ."C, 'Confirm' subroutine 

USAGE: When writing a macro which will delete or 

overwrite a buffer, call . *B while in that 
buffer to avoid unintended loss of its 
contents. 

."B should shortly be tested by SS, with the 
program continued or aborted accordingly. 

Recall that: 

JC = at Top of Buffer 
JT = at End of Buffer. 

JCI8T = only if both 8C and tT are 0, which is 
TRUE only for an empty buffer. 
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The Answer Subroutine, ."A 

This is the basic subroutine of this group. The character to 
which @K is to be compared is passed to it as a leading 
numeric argument. It makes the case-independent compari- 
son and sets the top of the stack TRUE or FALSE, accord- 
ingly. After a call the stack must be POPped (by @S or @S') to 
govern the desired action. 

It could have been held to a length of 9 bytes, by simply 
changing "s to @A in (9) and adding a comma: 



(9) 

(10) 



«K132=' 's 
«KI32=eA, 



8 bytes 

9 bytes 



However, by adding 5 bytes I can save myself the vexa- 
tion of forgetting to make the calling argument lower case: 



(11) 



«KI32=(eA132), 14 bytes 



You can see from USAGE in Listing 1 that a call plus the 
POP take 6 bytes, so I am saving only two bytes per call over 
the 8 bytes in (8) or (9). However, the real savings come, not 



Listing 2. Macros to expedite subroutine calls. 

"X*G ;GoBack (for MATE only) 
bytes 



106 



FUNCTIONAL SPECIFICATION: Returns to the 'heme' 
buffer, which has been saved in V7 (by 8BV7). 



1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 

27 bytes 



FUNCTIONAL SPECIFICATION: Pushes variables 0, 1, 
2, 7, 8, and cursor position on the stack. 
Loads variable, V7, with current buffer, 8B. 

USAGE: Normally called at the start of any macro 
which will alter more than one of the items saved. 



USAGE: 


87. 


'G 












8A=«B% 


;IF 


still in 


hcane buffer, do nothing 


8A=0{BTE} 


;IF 


SB 


was 


0, 


return 


to 


T Buffer. 


«A=1{B0E} 


;IF 


«B 


was 


1, 


return 


to 


Buffer 0. 


«A=2 (BIE) 


/•IF 


«B 


was 


2, 


return 


to 


Buffer 1. 


SA=3{B2E} 


;IF 


SB 


was 


3, 


return 


to 


Buffer 2. 


8A=4{B3E} 


;IP 


8B 


was 


4, 


return 


to 


Buffer 3. 


«A=5<B4E} 


;IF 


8B 


was 


5, 


return 


to 


Buffer 4. 


«A=6<B5E} 


;IF 


iB 


was 


6/ 


return 


to 


Buffer 5. 


8A=7{B6E> 


;IF 


iB 


was 


7, 


return 


to 


Buffer 6. 


8A=8{B7E} 


;IF 


iB 


was 


8, 


return 


to 


Buffer 7. 


SA=9{B8E} 


;IF 


(B 


was 


9 , 


return 


to 


Buffer 8. 


«A=10{B9E} 


;IF 


8B 


was 


10 


, return to Buffer 9 . 


*X'S ;SaVBEnv 














2 



80,81,82,87,88, 

«X,8L, 

eBV7 



;Push variables VO ,V1 ,V2 ,V7 ,V8 on stack. 1 
;Push current col. and line no. on stack. 2 
;Put current buffer no. in variable, V7. 3 



*X"R 



; Restore 
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87. 



8S-8LL 
8SQX 



FUNCTIONAL SPECIFICATION: Restores the 
environment saved by the SaveEnv macro. 

STACK USE: 7 out of the 16 levels available. 

USAGE: Must be invoked when exiting a macro which 
has used SaveEnv, ."S, whether that exit 
was normal, a conditional exit, a jump, or 
a programmed abort. 

If the macro is aborted with Ctrl-C or 
terminated accidentally, the variables must 
be reinitialized, manually or otherwise. 

;GoBack to 'home' buffer (MATE). If you 1 
; are using ZMATE or PCMATE, replace this 
; with B87E. 

;Move from cur. line (8L) to saved line. 2 
;Move to saved column no. (8S). 3 



from shortening this macro, but from making it available as a 
permac callable by other subroutine macros with a passed 
byte argument. 

The Y(es), N(o), and Q(uit) Subroutines. 

Next I found that, among macros usually in memory, I 
was comparing @K with "Y 7 times, with "N 6 times, and 
with "Q 4 times. Having the Answer subroutine already in 
memory, I could justify writing 3 new 4-byte subroutines: 



NAME 




CODE 


USAGE 


Yes ' or 


.'Y: 


' 'Y.'A 


."Y8S 


No' or 


.'N: 


■ 'N.*A 


.'Nes 


Quit ' or 


.'Q: 


"Q.-A 


."Q8S 



Source listings for these are so trivial that I have included 
but one, ."Y, just for completeness. 

You will have noticed that there is an extra flexibility in 
these subroutines that was not available with the raw testing 
of @K. The comparison can be made when convenient, but 
the result made use of later on in the program. Thus, for one 
thing, you could ask several questions, pile up the answers 
on the stack, then govern some action by a complex boolean 
expression through judicious use of the POPs, (e.g.: 
(@S&@S')!@S). 

Next, if you look through your macros for occasions when 
you have compared @K with "Y or "N, you may be able to 
make up a subroutine that is a great space saver. I found that 
I was asking for confirmation many times before overwriting 
a file or deleting a buffer. This led to the next example: 

The Confirm Subroutine, ."C 

As you see from the listing, this routine is just as simple as 
.Y, having only two commands. Because of the string, 
though, it is 50 bytes long, compared to 4. Since it takes only 
4 bytes to make use of it, it is a wonderful time and space 
saver in writing macros. 

You note that .''C calls .^Y, which calls ."A. Let me finish 



Lialing 3. A subroutine to accept a string of characters. 

'X'P ;Prompt 68 

bytes 

FUNCTIONAL SPECIFICATION: Inserts 3 blank lines and 
displays, as a prompt, the one string argument 
passed to it. Tags the string response, which 
is terminated with a CR. 



VARIABLES USED: 
was typed. 



V8,- flags calling macro if an ESC 
so it will abort. 



USAGE: The caller will normally save V8 and the 

cursor position on the stack before calling and 
and restore them, as well as the CRT screen, at 
the end. 



OL 

3[13I] 

-2L 

91 

QAI*AA$ 

91 

T 

[ 



;Move to column 0, current line. 

;Open up 3 lines to set off prompt. 

;Move to middle line 

;Tab, to indent prompt (for esthetics). 

;Insert the one string argument (prompt), 

;Another Tab (more esthetics). 

;Tag iDeginning of user input. 

;Begin an iteration on keystrokes: 



GEsc to EibortS; 
8K=27V8 ; 

8K=13188_ 
8K=127{ 



A comand-line message. 

IP an ESC (27) was typed, store TRUE 

in V8, ELSE store FALSE. 
IF a CR or an ESC, escape loop. 
IF a DELETE (127) , 

delete previoua character and loop. 
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PMATE SYSTEM — > 



I MATE I ZMATE | PCMATE | 



1 Numeric variables j 10 j 10 | 100 j 
1 1 (1-digit) 1 (1-digit) j (2-digit) | 


1 Variables preloaded by | | | «0 = Day | 
1 PMATE. (if system has a j None j None I *1 = Month | 
1 built-in calendar/clock) | | j 82 = Year j 


1 Supports B«SE, etc. | No j Yes j Yes | 


1 Supports . .b (execution of | | | | 
1 buffer b beginning at the | No | No j Yes | 
1 Cursor position). III! 



Tabl* 1. Differences among MATE, ZMATE, & PCMATE identified to date. 



off this chain, for now, with a routine which calls .'*C. 

The Buffer Test Subroutine, ."B 

I mentioned earlier that there are ways to guard against 
destroying your buffers, even with MATE. Well, this is one 
of them. If the buffer is empty, your macro can go right 
ahead and use it, without bothering you. If it is not, it will 
ask if okay to destroy it. If yes, it can go ahead. If not, your 
calling routine will have to decide what to do. 

Macros to Expedite Subroutine Calls. See Listing 2. 
The GoBack (to home buffer) subroutine, ."G 

This subroutine enables MATE macros to return to a 
buffer previously saved on the stack or in a Variable. For 
ZMATE and PCMATE, B@SE performs that function much 
more concisely. 

The SaveEnv and Restore Subroutines, ."S and ."R 

These two save and restore the environment when your 
rjiacro is going to move the cursor, go to a different buffer, or 
simply use certain variables. I must confess that I am just 
now adding these to my own permac area. What pushed me 
into it was the thought of having to write much of them over 
and over again,- with comments,- in each new macro listing. 

Consequently, I expect to be adding to and modifying, 
them over the next several columns. In particular, I wonder if 
using up 7 stack levels will prove to excessively constrain 
any macros which would otherwise call .'*R. 

A Macro to Accept a Multi-character Response. 
See Listing 3. 

The Prompt Macro, ."P 

This macro is simply an attempt to extract all of the code 
common to several macros which ask the user for a multi- 



If computers ever become too powerful, 
we'll just organize them into a committee. 

That'll do them in! 



character response. It displays a 
prompt passed to it and tags the string 
response. 

For a string of digits, the cjJler may 
store the number in a variable, with #.D 
(using our decimal macro from the first 
column). Other strings are usually 
moved to a buffer, with #B2C, for ex- 
ample. 

This should be much clearer with an 
example, which [follows:][will have to 
wait for another issue.] 



A Search Macro with Optional 
Change. 

The Change Macro, .C 

This macro invokes .T twice,- first 
for the 'search' string, and then for the 'replace' string. It 
searches in a forward direction only and starts wherever you 
place the cursor. It is my feeling that options, such as 'search 
direction' and 'globed', are more trouble to answer than it is 
to move the cursor to where you want to start (at least 99% of 
the tim^e). 

This is most useful, of course, when bound to a key so it 
can be called as an instant command. I have it invoked by 
ALT C, in both MATE and PCMATE.* 



Listing 4. A search macro with optional change. 

XC ; Change 97 bytes 

FUNCTIONAL SPECIFICATION: Calls . "P to display the 
proDipt, 'Change:'. Waits for user's response, 
terminated with a CR. Moves response to Buf. 2. 
Calls .'P to display To:'. Moves s response to 
Buf. 3. Clears the pron^t area and performs an 

iterative search for buffer 2 contents with 
optional change to buffer 3 contents. 

VARIABLES USED: V8 Set by .*P if user types an ESC 



BUFFERS USED: 



SUBROUTINES: 



SIDE EFFECTS: 



2 Holds search string. 

3 Holds replace string. 
. 'S SaveEnv. 

."R Restore. 

. 'P Proo^ 

As written, this will destroy any 
contents of buffers 2 and 3. 



USAGE: Before calling, the cursor should be moved 
to or above the line where the search is to start. 



■s 



PChange:$ 
88' 

<#B2C} 
.''PTo:$ 
«8' 

{#B3C} 
-2L6K 
[ 

EUS*A82$ 

8B_ 

GRET to change 

«K=13 

{ 

-C*Ae2$'Ae3$ 

} 

eK=27 
] 

.^R 



Save the environment. 1 

Display request for string to change. 2 

If an ESC was not typed by the user, 3 

Move the string typed to buffer 2. 4 

Request replacement string from user. 5 

If an abort (ESC) was not requested. 6 

Move the string typed to buffer 3. 7 

Remove the entire prompt area. 8 

start loop. 9 

IF an !Ux>rt was requested, escape looplO 

ELSE search for string to change. 

IF not found, escape loop. 
ESC to terminate. $ ;Cnid line Msg. 

IF a CR was typed. 



Make the change. 

IF an ESC, escape loop. 
ELSE loop & continue search. 
Restore the environment. 



11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
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Z-Best Software 

Birth of a New Program 



By Bill Tishey 



Anyone who accessed the message board on Jay Sage's Z- 
Node this past December and followed the thread on devel- 
opment of XFOR.COM by Gene Pizzetta had a real treat. Not 
only did you get to follow development of a program from 
its conception to release, but you were able to witness the ex- 
citement and enthusiasm of user-involvement in its develop- 
ment. 

Background: ZFILES.LST and the Z-SUS Database 

This whole episode should probably start with a discus- 
sion of ZFILES.LST which I have been updating monthly for 
the past several years. ZFILES.LST was a list of Z-System 
program and utility versions (released 
and pending), originally published by 
Echelon in their Newsletter Z-NEWS 
#602 (10/6/86). The list at that time 
contained 130 programs, and only con- 
sisted of the filenames and version 
numbers for each program. Steven 
Gold updated this list in April, 1988, 
using the same format, and I began updating the file a few 
months later, but expemded the format to include, on a single 
line: the filename, latest version num- 
ber, latest version of ZCPR supported, 
date issued, size in kilobytes, size in 
records, CRC, a remarks field, and, 
more recently, the Z-SUS distribution 
disk on which the program appears. In 
short, ZFILES.LST has been used to 
catalog the latest Z-System programs 
and utilities and to provide some es- 
sential statistics for each pertinent 
.COM file. Figure 1 shows the header and a typical entry. 
Note that an asterick ("*") preceding the "Remarks" field 



Bill Tishey has been a ZCPR user since 1985, when he found the right combina- 
tion of ZCPR2 and Microsoft's Softcard CP/M for his three-year-old Apple 11+ . 
After graduating to ZCPR30 and PCPI's Applicard CP/M, he did a "manual in- 
stall" of ZCPR3.3 (with help from a lot of friends!), and in late 1988 switched to 
NZCOM and ZSDOS, all on the same vintage Apple U+. Bill is the author of the 
Z3HELP system, a monthly-updated system of help files for Z-System programs, as 
well as comprehensive listings of available Z-System software. Bill is the editor of 
the Z-System Software Update Service and has compiled such offerings as the 
Z3COM package and the Z-System Programmer's Toolkit. Bill is a language analyst 
for the federal government and frequents the Foreign Language Forum (FLEFO) on 
CompuServe. He can he reached there (76320,22), on Genie (WATISHE), on Jay 
Sage's Z-Node #3 (617-965-7259) and by regular mail at 8335 Dubbs Drive, Sev- 
ern, MD 21144. 



indicates a commercial or proprietary program and "?" indi- 
cates a pending program (under beta- testing). 

ZFILES has continued to follow this format. This past Oc- 
tober, however, after several weeks of rooting through my 
archives (which represent months of download time!) and 
reorganizing and updating data, I put together a fairly com- 
prehensive database of the Z-System files released over the 
major Z-Nodes during the past five years. Though still not 
complete, I think it's a good beginning toward cataloging not 
only all the great programs and utilities, but also the aliases, 
patches, tips, et cetera, which continue to be generated in 
support of Z-System. The database is being maintained in 



Name 


s 

Y 
Vers S ZSUS Issue Size Recs CRC 


RfimarJcs 


FOR 

Figure 1 


1.20 V203 01/91 4k 29 7715 


XFOR12.COM 



dBase III+ on my '286 clone. As of this writing, it contains 
over 700 entries. I've been transferring various pulls from the 



Name 


Vera 


S 
Y 
S ZSUS 

V203 
Llity for 
irce file 
ZCNFG. 


Siz Rec CRC 

4 29 7715 
displaying 
specificati 


Library/Size 


Issued 


Author 


XFOR 1.20 
Z-System FOR utJ 
Command line soi 
can be set with 

Figure! 


XFOR12 38 12/23/90 Gene Pizzetta 

" " delimited file catalogs. 

3n. Nximeroua configuration options 



database to my CP/M-equipped (PCPI CP/M, NZCOM, 
ZSDOS) Apple 11+ via a null modem and doing final-editing 

in WordStar 4.0. 
The first product of the Z-SUS data- 
base was ZFILEVOl.LST, a "verbose" 
version of ZFILESxx.LST (the original 
list, now the "brief" version, has been 
renamed ZFILEBxx.LST and continues 
to be updated monthly). ZFILEVOl.LST 
was in respor^e to a number of re- 
quests to include a brief description of 
each of the program entries in ZFILES. 
Now, those who have no idea of what 
things like LSH, SNAP, TCSRC, OE, et 
cetera, are, can get a reasonable idea of 
what those programs do. 
ZFILEVxx.LST will be updated "peri- 
odically" (possibly monthly, but at 
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least two or three times a year). Its header and a typical entry 
are shown in Figure 2. 

Another purpose of ZFILEVxx.LST was to provide the 
name of the original library in which a Z program was dis- 
tributed. Since the .COM files often have different names 
than the libraries in which they are distributed, this is very 
important to users attempting to track down the programs. 
The Z-System Software Update Service had also talked about 
offering to compile custom disks for its customers. Providing 
the size of the libraries made it easy for users to mix and 
match programs to fill a particular disk format. 

The database also allows for grouping files and programs 
according to categories. While I've always maintained special 
disks for word processing, programming, communications, 
system, file, disk, print functions, et cetera, all files can nowr 
be pulled together according to these and other categories. 
Again, this has potential for use in com^piling special pack- 
ages for Z-SUS customers and has already helped signifi- 
cantly in producing the Z-System Programmer's Pack (see 
armouncements in this issue). 

The database is also helping me to keep track of programs 
for which .HLP files for my Z3HELP system (a subject for 
another column!) have yet to be written. I'm^ a firm believer 
in documentation. Taking the time to define the syntax, func- 
tion, and usage, as well as the traps and limitations of a pro- 
gram, makes it much more meaningful and useful to those 
who would use it. For those who maintain a system with 
many types of programs, HELP files are a good way to or- 
gani2:e and make this information easily accessible. 

Other ideas I've had for "lists" from the database include: 

1) programs supporting the various versions of ZCPR 

2) programs supporting CP/M+ 

3) programs supporting the various types of datestamp- 
ing (DateStamper/ZSDOS/Z80DOS) 

4) programs for which .CFG files have/have not been 
written 

Special packages can be compiled for: word processing, 
system control, file manipulation, datestamping, alias appli- 
cations, et cetera. Maybe the readers have other ideas. If so. 



I'd like to hear of them. Now, let's get back to the XFOR 
saga. 

A "Spruced-Up" FOR 

When I released ZFILEVxx.LST this past November, Bob 
Dean m^ade an excellent suggestion to meike the list "FOR"- 
compatible by adding a " — " delimiter between each file 
record. FOR.COM, in its various adaptations (FORZ, ZFORP, 
etc.), is a tool used on remote access computer systems 
(RAS), originally created by Irv Hoff, to provide on-line de- 
scriptions of available files. FOR is configured to read one or 
more .FOR files which contain the actual descriptions and of- 
ten reside in a private, protected area. Making ZFILEV 
"FOR"-compatible would allow users to scan ZFILEV on- 
line to view the essential stats and descriptions of particular 
programs in which they were interested. 

Shortly after I released the modified ZFILEV, Chris 
McEwen noted that he had patched his existing FOR utility 
as well to read the file and was calling the resulting file DF 
(Describe File). Users on his RAS now could also scan the list 
for any number of things: function, program, author's name, 
date, etc. Chris was quick to notice that a modified FOR 
might be useful for both RAS and personal use in scanning 
all kinds of lists (including Ian Cotrill's listing of Remote 
RCP/M systems, RCPMmmyy.LST, which he updates 
monthly). He presented to Gene Pizzetta the idea of "spruc- 
ing up" FOR, and Gene took up the challenge. Almost imme- 
diately. Gene was deluged with "suggestions." He showed a 
great deal of patience and understanding, however, in han- 
dling suggestions from many sides and credit is due him for 
keeping everyone's interests at heart. The result is truly a 
program of great utility for everyone. I captured most of the 
discussion thread and offer below a fairly accurate chronol- 
ogy of events. What I've tried to show is how the comments 
and suggestions (left column) greatly influenced the develop- 
ment decisions (right column). Note that the comments have 
been heavily edited to save space. They were actually offered 
with much friendly discussion and not in the rather curt way 
they may appear. 



VsO.1 (Dec 2, 1990) 

Armed with the suggestions below, Gene set to work and, within a few days (!) released version 0.1. Everyone agreed that it 
was a good start. ZFOR, as it was initially named, was based on Carson Wilson's FORZ 1.0 (8/5/87), which was a revised 
disassembly of Irv Hoff's FOR.COM. As a standard Z tool, it responded to the "//" option on the command line, set the error 
flag on a non-match, sported a quiet mode, and could be re-invoked with the GO command. It was also configurable with 
ZCNFG. 



Comments and Suggestions: 

Consider the following syntax: FOR [ for-file-name [ search string ] ] By allowing the text file to 
be specified on the command line, a single FOR.COM could be used (via ARUNZ or other 
aliases) to work with various text files; one would not, as one does at present, need a separate 
COM file patched for each text file. 

The way to handle the problem of looking at files that are not in the public area (sonrie FlAS's 
keep FOR files in a private area) is to provide an intemal default path (settable with ZCNFG). If 
no explicit DU: is given, the file would be fetched from the default directory. 

Perhaps we could have a default filename and DU: for stand-alone use (those not using it in 
conjunction with ARUNZ or aliases). 

Yes, allow a default name and directory, but use that file only if the program is invoked with an 
empty command line teul. Otherwise require that the first token be the file spec and any remaining 
tokens be search words. 



Development: 

ZFOR adds command-line source file 
specification. 



If no DU or DIR spec is given, an internally 
configured default directory Is used or, if not 
configured, the currently logged directory. 



If no command tail is given, ZFOR defaults 
to the configured intemsd filename. 



34 



The Computer Journal / #49 



Vs 0.2 (Dec 8, 1990) 

Some confusion resulted from users' misunderstanding of the command line parsing. Many configured an internal filename 
and DU and, using it in a stand-alone situation (not called from an alias), discovered they couldn't look for a search string 
without giving the filename. The result was some thinking that the new FOR didn't provide string-searching! Gene reassured 
everyone that this function had been in FOR from the beginning and that he had only made some very minor changes to it. 
Besides, an alias such as "FOR zfor al5:for $*" would allow you to simply type ">FOR string" to get the job done. Some, 
however, continued to insist on the flexibility for stand-alone use. 

With this version. Gene added a three-way screen paging option: paging, continuous scroll (using "S to pause), or asking the 
user whether to page or not. Leading spaces were also made significant. Only one space after the filespec is skipped; multiple 
spaces are part of the first search string. This allows looking for " ten" and not getting "referRENce". 



Comments and Suggestions: 

FOR is useless without string search, and ZFOR seems to accept a filename parevneter OR a 
string. It needs t>oth. 

What would you think of the following syntax (and new name): "XFOR string"~use Internal 
fileneime sind directory; "XFOR [D][U]:file string"~use specified file. The colon indicates that the 
parameter is a filename. 

Another name should be used rather than ZFOR as that naime Is used In ZMD. 

You might delete the " — " between entries and highlight the entry as well. That might allow 
more data on the screen while still keeping it separate. 

The entries should be separated either by the "— -" or a CR/LF. To remove both is too much. 
For ZFILES, the display is a bit too cluttered. 

I like the ZFILES header and would like to have a different one for the Nolan format (which 
includes the DU:, file size and date on the same line as the filename). 

I kept getting the message that the buffer was overflowing, which ended the search. 

Consider adding some additional abort chtiracters more in line with Irv Hoff's FOR, specifically 
K,k (non-control). 

How about the ability to use file wildcarding In tiie search stiing? 
It would be nice to allow for multiple search words. 



Development: 

The syntax was changed so that, if the 
first token contains a colon, it is a filename. If 
either the DU/DIR spec or filename is 
missing, they are filled in from the configured 
defaults. This allows a string search to be 
made if a DU is given without a filename. 

The name was changed to XFOR to avoid 
confiict with ZMD utilities. 

The first line of each entry is highlighted if 
available from TCAP. Reverse video is used 
for header line, if available. 

Configurable to allow a blank line between 
entries on screen. 

Provides for an additional roll-your own 
header in the form of a patch file which can be 
overiaid into the program. 

The entry buffer now handles single 
entries up to 8k. 

XFOR can be aborted at any time with "C, 
"K, "X, C, K,orX. 

Search strings may include the following 
special characters: "|" - separates multiple 
search strings, 'V - matches the beginning of 
a line, "?" - matches any single character, 
allowing primitive wildcard searches. 



Vs 1.0 (15 Dec, 1990) 

In this, the distribution version. Gene changed the method of making leading spaces significant after discovering that the 
syntax would not work from an alias (ARUNZ purges the leading spaces). Leading spaces are now ignored unless the match 
string begins with " | ". "XFOR Al: | REN", thus, searches an internally configured file in Al for an entry beginning with 
"REN". 

Gene also added use of direct cursor addressing and clear-to-end-of-string if available and if a header is displayed. This 
allows the header to be printed once and not flicker at the top of the screen. 



Comments and Suggestions: 

Suggest that TCAP use be optional and that the screen NOT be cleared (or at least be config- 
urable). 

Under the old TCAP, after the first few screen fulls of a ZFILES search, 

the first line in each file description has the spacing to the end of the line in reverse video. 



Development: 

Variable screen overiap and cleeu^ing the 
screen before each page are now configur- 
able options. 

Fixed problem causing highlighting not to 
be terminated on some machines. 



Vsl.1 (18 Dec, 1990) 

Some minor changes were made in this version, including addition of a CR, LF after the paging question and the use of 
BOUT instead of COUT in the print loop so that tabs are expanded. 



Comments and Suggestions: 

It'd be nice to redirect output to a file, printer, or append it (ala CONCAT) to an existing file. 

You might wish to add a way to turn on and off the highlighting of the first line of each entry. 
Perhaps ability to choose no reverse ceui be built into the ZCNFG file. 



Development: 

Added printer output and "+" command 
line option (last token preceded by a space). 

Made video attributes used for header and 
first line of entry configurable options. 
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Vs 1.2 (23 Dec, 1990) 

Just when everyone seemed adjusted to the new command line syntax, a suggestion was made to change it (where have I 
heard that before?): the creation of an option field preceded by a slash. This idea was too good to ignore, since it would 
simplify adding new options (as long as there was a good tokenizing routine) and avoid seemingly "glued-on" enhancements 
such as the "+" command for printer output. 



CommentB and Suggestions: 

How atxjut the following syntax: XFOR [[DIR]:[FILE] [/options] [strings] Some possible options 
include: H-header, P-page, S-space between lines, L-print, N-no paging, etc. 



Dsvslopment: 

Changed command-line syntax: an option 
list, preceded by a slash can now be included 
in the command line, just before the match 
string. Options: H-display header, A-use 
attemate header, S-double space between 
entries, L-echo to printer, V-tum off all screen 
attributes, P-use screen paging, N-no screen 
paging. 

V8 1.37 

Finally, there were some hngering suggestions to consider for future updates. Some of these were dismissed for obvious 
reasons. The ability to read "crunched" file lists, for instance, had been suggested early on, since many of the file lists take up 
much disk space (ZFILEVxx.LST is 120+k). The speed tradeoff in uncruching, however, may not be worth adding this option. 

The ability to expand an '*' to '???' in a search was also suggested but considered undesirable. Every special character 
added to the search mode, of course, is another character which cannot be searched for, and these should be kept to an absolute 
minimum. In addition, the XFOR search is looking for strings, not filenames. Entering "xf*" would have exactly the same effect 
as entering just "xf. 



Comments and Suggestions: 

Consider using a CR to advance a screen, a SP to advance a line only and adding the ,. 
standard command. Consider also bacl(ward scroll (lil<e found in V.COM), If supported by 
extended TCAP. 

Could you add "N" as ein abort option at the end of each page and change the prompt from 
"More" to "More?". This would accommodate users not familiair with the RAS conventions ("C, 
-K, etc.). 

How about a new command ("S") while waiting for "More" to bring up a prompt looking for a 
new search string? 

I hope this little, ui\folding drama has not only informed 
you about XFOR, but also given you a taste of program de- 
velopment in the public domain (at least as it thrives among 
the Z-Nodes). As Bob Dean at one point noted: "One thing 
■about CP/M compatible public domain, it always has a gene- 
alogy a mile long." Indeed, XFOR's parentage can now be 
traced from Gene Pizzetta (XFOR), to Carson Wilson 
(FORZ), to Irv Hoff (FOR), who evidently got the idea from 



Development: 



CompuServe. In addition, the DU:, file size, and date fields 
were added to the FOR-file format by Gene Nolan and Bob 
Dean. As with most other CP/M and Z programs, credit is 
also due the many users and testers who took time to offer 
their suggestions and feedback. For XFOR, the major con- 
tributors were: Chris McEwen, Jay Sage, Bob Dean, Howard 
Schwartz, and yours truly.© 



continued from page 18 
room temperature is within some hysteresis band of the de- 
sired temperature, the circulator is cycled on for only one 
minute out of ten. Should the room temperature fall below 
the bottom limit point, then the circulator runs continuously. 
This approach has been very effective. 

Design Goals 

The above description should give you a pretty clear pic- 
ture of the kind of sophisticated control that a microproces- 
sor based system can provide. I would like to close this in- 
stallment by saying a few things about some important de- 
sign constraints I imposed. 

I required that the system operate for an extended period 
of time without AC power. One would not want a power 
glitch to erase the programmed schedule and leave the elec- 
trical circuits and heating system uncontrolled thereafter. We 
might, after all, be away on vacation. A sealed lead-acid bat- 
tery, constantly charged from the AC, can operate the com- 
plete system for at least 10 hours. 



During the time that the power is off, some control opera- 
tions cannot be performed because there is no electrical 
power to the circuits being controlled. The system is smart 
enough to know that AC power has failed, to keep track of 
any state changes that should have been carried out, and to 
carry them out as soon as power is restored. 

A second requirement was that the system be highly 
failsafe. A complete failure of the computer must still result 
in a house whose temperature will stay within reasonable 
bounds. Failure of the controller with the boiler turned on 
must not lead to overheating and possible explosion of the 
boiler. Failure of the controller at a time when the boUer is 
turned off must not allow the house temperature to drop to 
the point where water pipes might freeze. We will leave the 
description of how this is done for next time. 

Finally, there must be full manual backup control. Electri- 
cal circuits must be switchable as usual with the computer 
controller turned off or completely removed. Under the seime 
circumstances, the heating system must fall back to normal 
manual control. This, too, will be described next tLme.# 
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continued from page 20 
and addresses are still entered as hex 
quantities. In a third level of abstrac- 
tion, numeric quantities and addresses 
are allowed to be represented symboli- 
cjJly, and the assembler takes over the 
chore of keeping track of the actual ad- 
dresses. Instead of getting buried in the 
details of assembler operations, let's 
start over from the viewpoint of the 
high level language, the next level of 
abstraction. 

From High Level to Assembler 

High level languages deal with data 
structures built up from numbers and 
strings. Operations performed on such 
data structures include arithmetic, logi- 
c£il, and I/O operations. To be sure, in- 
tegers may be defined as a byte and 
long integers as a word, but the empha- 
sis is on the data type. CPU registers 
appear in C, where some compilers al- 
low specification of an integer as a reg- 
ister variable. But the programmer does 
not specify which register is to be used; 
the compiler makes that choice. By con- 
trast, assemblers deal only with regis- 
ters and memory locations. Treatment 
of data as one type or another is en- 
tirely the choice of the programmer 
since a data structure is ultimately de- 
fined in terms of the operations which 
may be sensibly performed on the col- 
lection of data elements. 

Assembly Language Programming: 
Mnemonics and Opcodes 

As in any new language, you must 
become familiar with the actual in- 
struction set. There are three commonly 
used instruction sets, Intel, Zilog, and 
Intel modified for Z80. The instruction 
sets are implemented by assemblers. 
For ex£imple, consider the instruction to 
copy the contents of the C register into 
the B register. The Intel mnemonic is 
"MOV B,C", the Zilog mnemonic is 
"LD B,C". Both result in the same byte 
of code processed by the cpu: 41H. 
M80 is able to translate either Intel or 
Zilog mnemonics. Other assemblers 
use only one set. Learn the set that your 
assembler uses by any means possible. 
The 8080 has 244 instructions; the Z80 
has about 3 times that number. Don't 
despair, however. Most of the instruc- 
tions are variations on a basic set of 
about 20 (depending on how you count 
differences). This part of assembly lan- 
guage is like learning your addition 
tables - you just have to do it. As you 
write programs, many of these instruc- 



tions and their effects will become sec- 
ond nature. I don't remember the de- 
tails of all of them, even after many 
years of AL programming. But I know 
they exist and look them up when nec- 
essary. If you own ZMAC, then you 
know that there is a companion HELP 
file named Z80.HLP. Written by Cam 
Cotrill, Z80.HLP provides all the details 
for every instruction used by the Z80 
and Z180/HD64180 in quickly acces- 
sible form. The same data is to be 
found in tables included in references 1 
and 2. 

Assembler Instructions ~ Pseudo- 
Ops 

The cpu instructions discussed 
above are also referred to as opcodes, 
and mnemonics. They are assembler in- 
structions, because they instruct the as- 
sembler to generate code for execution 
by the cpu. There is another class of 
assembler instructions, commonly 
called pseudo-ops. This second class 
does not directly produce executable 
code. An important pseudo-op is the 
DEFB statement, which defines the con- 
tents of a memory location. Another is 
the ORG statement, which defines the 
address at which subsequent code is to 
reside during execution. Other pseudo- 
ops provide for conditior\al assembly 
of code or other aspects of the opera- 
tion of the assembler itself. The 
MACRO pseudo-op provides a power- 
ful facility for HLL-like features; 
RMAC generates Z80 code with the 
help of Z80.LIB, a library of macros. 

Pseudo-ops have always been a part 
of non-trivial assemblers. Each assem- 
bler, however, has seen fit to give dif- 
ferent names to the same function! The 
DEFB function in M80 was named DB 
in ASM, MAC, and RMAC. Another 
synonym is DEFM. SLR assemblers rec- 
ognize the synonyms that were being 
used by most assemblers of its day. 
ZMAC also recognizes and properly in- 
terprets pseudo-op synon)mis, includ- 
ing those introduced by SLR. You will 
become acquainted with the set of 
pseudo-ops that your assembler uses. 
Knowing about synonyms becomes 
important when you attempt to read 
source code from someone else whose 
assembler is different. 

Experienced AL programmers have 
become accustomed to the differences 
in source code languages, and work 
comfortably with all the variations. Not 
much different than High Level Lan- 

continued page 28 



8031 ^Controller 
Modules 



NEW!!! 

Control-R II 

V Industry Standard 8-bit 8031 CPU 

V 128 bytes RAM / 8 K of EPROM 

V Socket for 8 Kbytes of Static RAM 

V 11.0592 MHz Operation 

V 14/16 bits of parallel I/O plus 
access to address, data and control 

signals on standard headers. 

V MAX232 Serial I/O (optional) 

V +5 volt single supply operation 

V Compact 3.50" x 4.5" size 

V Assembled & Tested, not a kit 

$64.95 each 



Control-R I 

V Industry Standard 8-bit 8031 CPU 
< 128 bytes RAM / 8K EPROM 

V 1 1 .0592 MHz Operation 

V 14/16 bits of parallel I/O 

V MAX232 Serial I/O (optional) 

V +5 volt single supply operation 

V Compact 2.75" x 4.00" size 

V Assembled & Tested, not a kit 

$39.95 each 



Options: 

' MAX232 I.e. ($6.95ea.) 

• 6264 8K SRAM ($10.00ea.) 

Development Software: 

• PseudoSam 51 Software ($50.00) 
Level II MSDOS cross-assembler. 
Assemble 803 1 code with a PC. 

• PseudoMax 51 Software ($100.00) 
MSDOS cross-simulator. Test and 
debug 8031 code on your PC! 



Ordering Information: 

Check or Money Orders accepted. All 
orders add $3.00 S&H in Continental US 
or $6.00 for Alaska, Hawaii and Canada 
Illinois residents must add 6.25% tax. 



Cottage Resources Corporation 

Suite 3-672, 1405 Stevenson Drive 

Springfield, Illinois 62703 

(217) 529-7679 
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continued from page 16 

ACTION ,X LDX ( get its action ) 
,X JSR ( fire itl ) 

CURRENT_MCB is a pointer to the currently active MCB. The linked list is used 
from within an action to propel the interrupt through the list, firing each MCB's 
action. The constraint on this is that all MCB actions MUST fire before the next 



INITIALIZE MOTOR 



CODE ADD_M0T0R_TO_LIST ( mcb — mcb 



( 



uses X, D ;; Adds 
List of MCBs. ) 



a new MCB to the ) 



ASSEMBLER 

ANCHOR_MCB # USX 
NEXT_M0TOR ,X LDD 
,Y LDX 
NEXT_M0TOR ,X STD 

,Y LDD 

ANCHOR_MCB # LDX 
NEXT_MOTOR ,X STD 



NEXT " 
END-CODE 



JMP 



CODE FILL MCB 



( 
( 
( 
ASSEMBLER 

OA ,Y LDX 
01 ,Y A LDA 



mcb action sensor timer port # — mcb ) 
; uses X, D ) 

; Sets parameters in a new MCB ) 



STEP_B1T ,X A STA INY INY 



Parameters are accessed 
from the data stack: 
<number> , Y 
set to the appropriate 
variable, then the 
element is poped off of 
the stack. ) 

In Max-Forth 1 ,Y is the 
LSB and ,Y is the MSB. 
The Stack Pointer is 
incremented . . INY . . 
last to remove an element 
and decremented first to 
add an element. 



00 ,Y LDD 


»PORT 


,X STD 


INY 


INY 


00 ,Y LDD 


TIMER , 


X STD 


INY 


INY 


00 ,Y LDD 


SENSOR 


,X STD 


INY 


INY 


00 ,Y UX> 


ACTION 


,X STD 


INY 


INY 


NEXT ' JMP 











: ADD_M0TOR ( mcb action sensor timer port # 
FILL MCB ADD MOTOR TO LIST DROP ; 



FIRST_MCB 

>_WAIT t 

>SENSOR_ACTION 

DELAY_TIME i 

8000 

01 

ADD myiofi. 



MCB ) 

Action Routine ) 
Sensor Routine ) 
Reload Timer count ) 
Address of Motor Port ) 
Address in Port of Motor 



LEFT ( — ; motor left ) 
DI >PORT C( 

FIRST_MCB STEP_BIT + CS 
OR 
>P<»T CI EI 



RIGHT ( — ; motor right ) 
DI >PORT a 

FIRST_MCB STEP_BIT + Ct 
OFF XOR AND 
>PORT CI EI 



RUN_M0T0R_1 ( - 
OCIF mSKl CI 
EI 



; spin itl ) 



interrupt hits. These states or routines 
must be methodiceJly factored. If this 
system was to have 11 motors, the ac- 
tion and sensor routines would have to 
be very short! The list is completed 
when the Anchor MCB's action fires its 
RTI instruction. Once again, the list is a 
circularly linked list. The list is closed— 
the Anchor MCB points to the first 
MCB-the Last MCB points to the An- 
chor MCB. 

Nuts and Bolts (And Tools!) 

The code in listing 1. is the start up 
code. It is loaded into the NMIS-0021 
first. The postfix assembler is loaded 
next. Finally the code in listing 2. is 
loaded into the single board. The fol- 
lowing is a review of the highlites 
found in listing 2. 

The motor interrupt handler uses 
the 68HCll's Output Compare Timer 1 
(TOCl).The interrupt handler first ac- 
knowledges the interrupt. This pre- 
vents the firing of this interrupt upon 
interrupt exit. If the interrupt is not ac- 
knowledged, it will cause a recurring 
interrupt. Next the current 68HC11 
clock count is read from TCNT, added 
with the TIMEROFFSET variable, then 
stuck into the TOCl register. 
TIMEROFFSET in relation with 
DELAY_TIME determine the step settle 
time-TIMER_OFFSET is the fine tun- 
ing variable while DELAY_TIME is the 
coarse tuning variable. When TCNT 
catches up to the veJue in TOCl an- 
other interrupt will fire. The first MCB 
is accessed through the Anchor MCB 
and the cycle continues. 

In order to have things run 
smoothly, "things" must be set up 
properly.INITIALIZE_MOTOR con- 
nects the Anchor MCB to itself, sets the 
Anchor MCB's action to the Last ac- 
tion—the action that ends in an RTI. Fi- 
nally the Interrupt vector for TOCl is 
set in EEPROM. 

The last words in listing 2. are tools 
used to construct a new MCB and con- 
nect it into the list. Note how 
FILLMCB uses the Forth stack to get 
its parameters. 

"Spin It On!" 

The NMIS 7040 board is described 
quite well in New Micros documenta- 
tion. I still referred to the Signetics lin- 
ear manual for the actual connection of 
the SAA1027 chip to a motor. The 
SA A1027 is the heart of the '7040 board 
which has four SA A1027's built in. 
continued page 39 
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continued from page 6 
and switches, or provides minimal noise filtering that will 
be ineffectual in the face of an actual surge. Many users 
would be as well served with a $3 hardware store MOV 
protector that they discard and replace periodically, as they 
would with an expensive protector using the MOVs, which 
will also wear out. 

Computer Reliability 

. As computers spread into more and more critical areas of 
industry and government, their reliability assumes greater 
importance. No longer is computer failure, especially in net- 
works, just a matter of running down to the computer store 
for a new power supply or motherboard. In sophisticated 
computer installations, many people may be unable to do 
their normal work until their computers are restored. As In- 
fonetics' 1989 study of network failure costs showed, total 
failure costs far exceed hardware expenses to repair equip- 
ment, although these extra costs are often cor\sidered uncon- 
trollable and buried in other overhead expense. 

In addition to physical damage, the potential for costly 
data errors and "no problem found" disruptions from pow- 
erline disturbances makes computer power protection a poor 
candidate for minor cost savings. 

What Protection Do Computers Need? 

Computers need powerline protection which does the fol- 
lowing: 

• Provides low let-through voltage (under 250 volts peak is 
harmless). 

• Does not use the safety ground as a surge sink and pre- 
serves it for its role as voltage reference. 

• Attenuates the fast rise times of all surges, to avoid stray 
coupling into computer circuitry. 

• Intercepts all surge frequencies, including the high fre- 
quency internally generated surges. 

• Does not convert normal mode surges into common 
mode. 

• Does not degrade in service, or if it does, at least is thor- 
oughly safe in the event of thermal runaway and employs 
reliable status indicator circuitry. 

The Ideal Surge Protector 

The ideal surge protector would disconnect the load from 
the powerline for the duration of the surge, then reconnect it. 
Since this is not possible with today's switch technology, a 
practical approach is to present a high impedance to the 
surge and a low impedance to the power wave, coupled with 
surge storage and frequency attenuation circuitry that will 
remove the disruption and damage potential from the surge, 
without using the critical reference ground as a surge sink, 
but rather only neutral as the return circuit. 

Solution 

Power protection is important to the reliable operation of 
computer networks. Once the critical role of the reference 
ground is understood, and how it provides a "back door" 
entry into the low-voltage logic circuitry of a computer, net- 
work managers can make informed decisions of how to pro- 
tect their equipment. Protection which meets the criteria out- 
lined above without diverting surges to the reference ground 
will reliably protect networks, while surge suppressers which 
use the ground as a surge sink may well exacerbate computer 



problems. Computer power supplies are likely to be more 
surge tolerant than low voltage logic circuitry, and the deci- 
sion for network configurators should perhaps be reliable 
protection or no protection, but not the risky middle course 
of ground disrupting ordinary shunt suppressers.© 
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continued from page 38 
This chip does the step commutation logic and drives the 
motor. My motor was a disk drive stepper motor, used to 
move the head to specific track locations. The NMIS 7040 
board was jumpered to address 8000 hex on the 68HCll's 
address bus. 

The motor control driver is built with the ADDMOTOR 
word. All is pretty explanatory: the 8000 is the address in 
hex of the NMIS-7040 bocird, 01 is the actual motor address 
in the NMIS-7040 board. RUNMOTORl will start the mo- 
tor spirming. LEFT will spin it left, RIGHT will spin it right. 
LEFT and RIGHT can be typed while the motor is spinning. 
By modifying the DELAYTIME and TIMEROFFSET vari- 
ables while the motor is spinrung, you can change the speed 
at which the motor spins. For now, use DI to stop the motor 
from spinning. Later we will see a more precise way of stop- 
ping the motor. 

Until Next Time 

A lot of information has been presented for one article. 
Read through the code— the fundamental paradigm found 
within can be applied to a plethora of applications in the 
embedded controls field. In the next Article we will build 
onto the MCB and control the motor's behavior in terms of 
its acceleration. If I can find a suitable and inexpensive en- 
coder, we will incorporate that into our system. Until then 
have fun with Forth.© 
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continued from page 2 

Control Yourself! 

1 was chatting with Jay Sage one evening last month. The 
talk was on embedded controllers. 1 wondered if there wasn't 
a field of interest for CP/M users here. Actually, this was a 
loaded question. 1 knew that Jay had built a complete home 
control system out of an 8085 box some years ago. The good 
news is that he took the bait. His first eirticle describing this 
system is in this issue. Meanwhile, I baited Rick Swenton in 
Connecticut on X-10 modules. Not everyone is up to wiring 
their house to the extent that Jay hcis. As it happens, there is 
renewed message traffic on some of the systems around the 
country about X-10. Think we should go for it? 

Of course, the real action in embedded controllers is in 
industrial applications. Frank Sergeant, the winner of the 
Harris competition, debuts in this issue with his project. It is 
a dedicated floppy disk alignment machine sufficiently small 
to allow alignment of drives in the field. No more oscillo- 
scopes, no more downtime while the drive goes to the shop. 
Really a great article. Of course, it is not a trivial project and 
we will be presenting it to you in a couple of installments. 
Simply didn't have space to fit it cdl in one issue. This article 
shows the power of the Harris RTX chip and Forth in a real- 
world application. 

Readers will remember Art saying that he wanted to have 
more time to spend on his own projects. That was one of the 
reasons he decided to retire as the publisher of The Computer 
Journal. Lucky Art! Zilog called to tell us of the new member 
of the Z80 family. The Z181 seems to be one hot chip-built in 
USART, timers, the works. Since this is right up Art's alley, I 
passed them on to him. Zilog sent him an application board 
and he is busy in the workshop putting the new chip through 
its paces. We will have his report later in the summer. Initial 
reaction: great! Be on the lookout for more on this as it devel- 
ops. 

Meanwhile, Matt Mercaldo continues with his series on 
stepper control in this issue. Pay close attention to this series 
of articles. Matt is leading us into robotics. In reading his 
"author's bio," I fully expect to see "six legged mechanical 
men" running around this place some time in late summer. 
Fascinating. My wife. Ester, says she can't wait. She has al- 
ready arranged lodging with her sister. 

As the Z-World Turns 

Of course, TCJ wouldn't be TCJ without great articles on 
Z-System. Jay tackles an excellent topic this time around: 
modifying the NZCOM virtual BIOS. He puts out a general 
challenge for more work in this area. Applications are nearly 
endless, and whatever you can't accomplish in the BIOS, you 
can tackle with an lOP. Lindsay Haisley of Austin, Texas is 
hot of the trail with an upcoming article on that. 

The real strength of the Z-System community is the way 
people work together. Bill Tishey relates the dynamics of this 
in his Z-Best column. 1 have to admit to being an instigator, 
but the central figure. Gene Pizzetta, accepted a challenge to 
produce a new tool, accepted ideas from many people and 
produced a fine program. It is so good, in fact, that it is now 
standard issue on the Z-SUS catalog disk to provide an "on- 
line" search capability of the listings. As you may also know, 
Bill is the editor of Z-SUS, so his interest in the development 
process of new software comes naturally. 

Al Hawley, the sysop of Z-Node Central in Los Angeles, 
California, debuts in this issue with a series on assembly 
language for the high level language programmer. This is a 



twist on the topic as such people ctre already tuned to the 
concept of algorithms but tend to think at a more abstract 
level. It seems to me that Al's series could encourage some to 
get off the fence and try their hands at programming at the 
assembly level. This issue is a great start. 

I want to take a moment to mention a publication that also 
serves the CP/M and Z-System community. Lee Bradley 
publishes FAght Bits & Change in Newington, Connecticut. He 
had some very nice things to say about TCJ in a recent edi- 
tion. To be right about it, I need to admit that 1 have been 
enjoying Lee's work since the early issues of Pieces of Eight, 
the predecessor of the current publication. EB&C is less tech- 
nical, and less formally produced than this publication. I find 
it fun to sit down in the evenings and browse through an 
issue. You might, al.so. Drop Lee a note at 24 E. Cedar Street, 
Newington CT 06111. Subscriptions are $15 a year in the US. 

David McGlone is publishing the Z-Letter on a regular 
basis now. Unfortunately, I don't have any more information 
on it. I am told he does an excellent job. 

Well, friends, that is about all the ramblings I have for you 
this issue. Again, the great articles keep coming in, though 
there is always room for more. We should all take pride in 
our collective achievements as seen in these pages. I will 
leave you now to enjoy the journal. Before you do, however, 
I want to take a brief moment away from the topic of com- 
puters and talk about someone very special to me. 

A Very Special Person 

Several readers noticed a fish symbol in the masthead of 
the last issue. The fish was a secret signal between early 
Christians during the time of the Roman persecutions. And 
yes, I am a Christian. But this is not a religious journal and 1 
had a deeper reason for placing it there. Bear with me as I 
want to tell you about it. 

One of the members of our Quaker Meeting for Worship 
founded the Central New Jersey chapter of FISH some 
twenty years ago. FISH feeds the poor, hungry and homeless 
and Anita Hoynes spent her life serving the less fortunate. 
When I found a moment, 1 would lend a hand but 1 never 
seemed to have enough time to give Anita. This last Christ- 
mas season found her organization swamped with a great 
many more needy families due to the deepening recession 
and with fewer people to help. Hers is not a small project: 
Anita's chapter feeds thousands of families. And so it was 
particularly hard for me to deny her call for help. The de- 
mands of putting out my first issue of this journal were such 
that 1 just could not be there for Anita. I was bothered greatly 
and as a small token, I placed the fish in the masthead. 

When Anita saw her first copy of TCJ, she was thrilled. It 
pleased her to see a friend doing well. I never heard a harsh 
word from this woman, though I felt I had let her down. But 
you should have seen her eyes when she found the fish! She 
knew immediately why it was there. For a brief moment, I 
thought I saw a glimmer of a tear in her eyes. My signal was 
received. 

This story takes a tragic turn here. Last week, Anita was 
violently murdered by one of the very people she spent her 
life serving. The loss of any life diminishes us, but losing this 
person has been very hard on me. We pray that we may gain 
our share of our Creator's Wisdom. In watching her, I found 
myself prajdng for a share of hers. 

Thank you for bearing with me on this. It really does 
mean a lot to me. And thank you, Anita, for showing the 
way we were meant to live our lives on this earth. Know that 
our love and faith is with you.# 
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continued from page 44 
veloping products like these are not for the garage type de- 
veloper. Now when it comes to problems add an extra 20 to 
40 thousand bucks for test gear. LANs require LAN sniffers 
to see what is actually happening. We found our interface 
program was combining two packets together if reset during 
a previous operation. Without the sniffer I doubt I would 
have ever found the problem. 

From an installation standpoint, LAN security is a major 
problem. When I installed a Novel system several years ago, 
the major problem was getting the new users to understand 
the importance of security. After that step it was figuring out 
how to set up the structure which can become a real manage- 
ment problem for some small organizations. The original 
group was 3 people with plans to add more later. My feeling 
after the project was too far along to change, the LAN was 
over kill by many times. It cost everybody lots of time, 
money, and added an extra layer that new or beginner users 
have to learn. For three people the $25 network would most 
likely be the best, and after they become larger and higher 
skilled, only then add a LAN option. 

The last or latest problem is using true blue products. We 
have a model 70 that has been locking up for no apparent 
reason. We have had previous problems with the 80 and are 
starting to think they are related. It seems IBM has a habit of 
selling systems with old problems, bad ROMs, or boards that 
have been recalled. The latest problems are ROM BIOS re- 
lated and might be affecting the 70, 80, and 90 models. They 
lock up after doing disk accesses and need a special work 
around driver. It is not so much a problem that the IBM 
products have bugs, all products have some amount of prob- 
lems. The main difference is finding out about it, we found 
out by buying one. The industry has an attitude that anything 
IBM does is ok and problem free. The truth is far from that. 



that assembler is the best way to get systems up, and not 
metacompling (metacompling uses a Forth system to gener- 
ate a new Forth system). 

Overall our opinion of the Forth Day was rather low key. 
The people seemed tired, and not with over work. Many of 
us Forth people get tired of being put down by C people 
when we can prove how much faster and better the code use 
is when in Forth. One bright spot was the talk about how 
SUN Computer Systems is using Forth in every one of their 
systems. Pretty soon there will be more embedded Forth sys- 
tems out there than any other language. The flip side of that 
is that most SUN user have little if any knowledge of that 
fact. Once the system boots and works properly they have 
little contact with Forth. For Sun it has been a good move 
that has saved money and provided lots of extra benefits. For 
the Forth community it will probably help in the long run, 
but for now just try and get a job doing Forth programming. 
Employers want C and more C programmers, nothing else 
will do (mainly because they are cheap and plentiful). 

Time to Go 

I guess I have said enough for now. Hopefully I have got 
some of you to rethink whether or not new technology is 
always better. I still remember attending a talk by Schu- 
macker of "SMALL IS BEAUTIFUL" fame. Lately I have 
been associating some of his ideas against the direction and 
type of products the computer industry is turning out. I have 
also found out that my best running and trouble free pro- 
grams are those which are small and simple (also usually in 
Forth!). The bigger and more complex they get it seems the 
worse they work. Sounds like small is beautiful after all.* 



Forth Day 

A few of us went to FORTH DAY 1990 in the San Fran- 
cisco bay area last month. Heard some good speakers for 
such a low key affair. About 30 to 40 people showed up with 
about 10 to 12 speakers. Chuck Moore was there and talked 
about his latest cpu project. He keeps making them faster 
and smaller. Has a whole CAD system in less than 64K of 
memory. The real interest for us and many others was the 
availability of EFORTH. That is a Forth especially set up for 
use in embedded systems. Dr. Ting had a hand in it's pro- 
duction as well as selling books about it. 

You can download the files from the GEnie Forth confer- 
ence as well as many other places. I am in the process of 
porting it to the 68K system at work to check out the use of it 
instead of our old debuggers. It has 29 to 31 words that 
require redoing in assembler for whichever CPU type you 
are using. All the other words are high level and would not 
need changing. The documents with it suggest about a 
month to port it over, but it looks like mine will be ready to 
try in one or two days of work. What will take long to do is 
setting up the code for ROM use, where it will require closer 
checking of RAM and ROM usage. They have a sample 8051 
version to show how simple it can be. The code runs on a PC 
and they use standard MASM 5.1 for both the PC and 8051 
version. The idea is to use define statements for other CPUs 
since only 31 words maximum need coding. That coding can 
also be rather simple so I would agree that for some CPU 
type just use defines. The most interesting concept stated was 
that metacompling was dead. It proved far too complex for 
most people to learn and just turned users away. Eforth is 
assembler based and I am glad to see more people realizing 
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The Computer Comer 



By Bill Kibler 



Well it is move time for me. Just moved to a larger place, 
but my computer space is actually smaller. Looks like it will 
take some time to get set up again, but we are now on a dead 
end road with considerable peace and quite as well as room 
to spread out later. 

Went to a computer swap last week and sold mostly disk 
drives and cabinets. Seems most shoppers are not interested 
in parts of systems any more, just PC based plug-in uruts. 
That also agrees with my part time teaching in electronics. 
The college is planning on changing the slant of the program 
to a more black box approach. 

Enrollment in pure electronic courses has fallen rather 
sharply, so the department is changing from an electroruc 
tech approach to a computer or industrial computer mainte- 

No longer is it necessary to be able to trouble 
shoot to the component level. Most systems these 
days can not be repaired to the component level so 

teaching that operation is proving pointless. 

nance approach. The students will spend their time doing 
mostly black box style repairs. No longer is it necessary to be 
able to trouble shoot to the component level. Most systems 
these days can not be repaired to the component level so 
teaching that operation is proving pointless. 

This point was brought home when I went to start the last 
semesters teaching. My classroom had been taken over by the 
computer department. I found myself stuck in a regular 
classroom and the two electronic labs were now only one. 
The electronics department has two instructors, while the 
computer group has gone from 4 to 6 and may add one more 
next fall. Computer science is not slowing down around 
here. 

Hardware Talk 

While at a recent family get together, I found that comput- 
ers can creep into the conversation as well. 1 was asked sev- 
eral times about what current level or model one should get. 
Personally, I still am not too happy with the PC clones but 
they are the cheapest still. 1 prefer the 68000 based units for 
their better software, but alas the PC market has more overall 
appeal for the beginner and college bound student. One of 
my brothers has two college bound students and they are 
finding out how many of the instructors are using and re- 
quiring the students to use PC based programs. 

The cost and availability of PC clones is so great that de- 
spite their draw backs they are by far the best buy. One of the 
people at work attended the computer show in Las Vegas, 
where he saw several sharp items. We still think the new 



Atari machines are the thing to have, as they can run Mac 
and DOS as well as the Atari ST software. The way they do 
this is using co-processor boards, the PC being a 386 plug in. 
The Macintosh is using the real Macintosh ROMs. So the ST 
becomes simply I/O for the other processes. 

For me personally, 1 have been thinking more and more 
along the lines of multiple processor systems. I do not have 
the room to have several systems for each of the many differ- 
ent areas I m^ay have to deal with. My wife is a teacher and 
wants to run Apple II programs and Macintosh graphic stuff 
(she is an art teacher as well as a graphic artist). My teaching 
is both Macintosh and PC clone. 1 work on clones running 
68K co-processors talking to Tandem mainframes. My real 
interest is in embedded systems which could be anything 
from 6805 to RTX2000s. I currently have hardware to support 
all but the Apple and Macs, and I plan to get a adapter card 
for my Atari ST to cover them. As you can guess, that is a lot 
of physical systems, especially when you throw in the older 
CP/M S-100 boxes. Takes up lots of room. 

What 1 am thinking about is retooling the old S-100 prod- 
ucts (or some other bus) to be able to put together one system 
that would run all the processors I am working with. I can 
currently run the Xerox CP/M programs on a PC clone and 
some special co-processors. There are several programs and 
adapters for the Atari ST to run Macintosh, CP/M, 8 bit 
Atari, PC/DOS, and many more. Apple is getting into the 
picture with a cheaper machine to run Apple II and Macin- 
tosh programs. The way things are going, I will be able to 
buy what I want before I could adapt and make such a sys- 
tem for myself. I sure hope so! 

Problems 

Work has been dragging along these days. Lots of little 
problems keep appearing to slow things down. We run co- 
processors in IBM PC based machines. Our latest project is 
changing our serial data path to LAN based usage. We ended 
up using a LAN sniffer the other day for one problem. The 
type and nature of test equipment is getting more and more 
complex everyday. I can't stress the importance of not going 
to higher tech solutions if there is some other way around the 
problem. To me, LANs are a good example of why I believe 
in that statement. 

First lets talk cost of development. We found that testing 
our program required at least 32 systems be on line before 
certain types of problems occurred. The cost of each system, 
even at OEM prices is staggering. The PC's are PS2 386's, 
plus LAN cards, our co-processor board, and added mem- 
ory. Our cost is over $7,000 each, and to do tests properly 
you need over 32 units or over $200,000 of capital outlay. De 

continued page 41 



44 



The Computer Journal / #49 



Plu*Perfect Systems == World-Class Software 



BackGrounder ii ^75 

Task-switching ZCPR34. Run 2 programs, cut/paste screen data. Use calculator, notepad, screendump directory 
in background. CP/M 2.2 only. Upgrade licensed version for $20. 

Z-System $69.95 

The renowned Z-System command processor (ZCPR v 3.4) and companion utilities. Dynamically change memory 

use. Installs automatically 

Order Z3PLUS for CP/M Plus, or NZ-COM for CP/M 2.2. 

ZMATE $50 

New Z-System version of renowned PMATE macro editor with split-screen mode for two-window viewing of one or 
more files. Extremely powerful and versatile macro capability lets you automate repetitive or complex editing 
tasks, making it the ultimate programmer's editor. Macros can be saved for reuse and also assigned to keys. 
Editing keys can be reconfigured for personal style. Supports drive/user and named-directory file references. 
Auto-installs on Z systems. Z-80 only. Supplied with user manual and sample macro files. 

PiuPerfect Writer $35 

Powerful text and program editor with EMACS-style features. Edit files up to 200K. Use up to 8 files at one time, 
with split-screen view. Short, text-oriented commands for fast touch-typing: move and delete by character, word! 
sentence, paragraph, plus rapid insert/delete/copy and search. Built-in file directory, disk change, space on disk.' 
New release of our original upgrade to Perfect Writer 1 .20, now for all Z80 computers. On-disk documentation 
only. 

2SD0S $75^ for ZRDOS users just $60 

State-of-the-art operating system. Built-in file DateStamping. Fast hard-disk warmboots. Menu-guided installation 
Enhanced time and date utilities. CP/M 2.2 only. 

DosDIsk $30 -$45 

Use MS-DOS disks without copying files. Subdirectories too. Kaypro w/TurboRom, Kaypro w/KayPLUS MD3 
MD11, Xerox 820-1 w/Pius 2, ONI, CI 28 w/1571 - $30. SB180 w/XBIOS -- $35. Kit - $45. Kit requires assembly 
language expertise and BIOS source code. 

MULTICPY $45 

Fast format and copy 90+ 5.25" disk formats. Use disks in foreign formats. Includes DosDisk. Requires Kaypro 
w/TurboRom. 

JetFInd $50 

Fastest possible text search, even in LBR, squeezed, crunched files. Also output to file or printer Regular 
expressions. 



To order: Specify product, operating system, computer, 5 Plu*Perfect Systems 

1/4" disk format. Enclose check, adding $3 shipping ($5 410 23rd St. 

foreign) + 6.5% tax in CA. Enclose invoice if upgrading Santa Monica, CA 90402 

BGii or ZRDOS. (21 3)-393-61 05 (eves.) 

BackGrounder 11 ©, DosDisk ©, Z3PLUS ©, PiuPerfect Writer ©, JetFind © Copyright 1986-88 by Bridger Mitchell. 



SAGE MICROSYSTEMS EAST 

Selling & Supporting the Best in 8-Bit Software 

• Automatic, Dynamic, Universal Z-Systems 

- Z3PLUS: Z-System for CP/M-Plus computers ($70) 

- NZCOM: Z-System for CP/M-2.2 computers ($70) 

- ZCPR34 Source Code: if you need to customize ($50) 

• ZSUS: Z-System Software Update Service, public-domain software distribution service 
(write for a flyer with full information) 

• Plu*Perfect Systems 

- Backgrounder ii: CP/M-2.2 multitasker ($75) 

- ZSDOS/ZDDOS: date-stamping DOS ($75, $60 for ZRDOS owners) 

- ZSDOS Programmer's Manual ($10) 

- DosDisk: MS-DOS disk-format emulator, supports subdirectories and 
date stamps ($30 standard, $35 XBIOS BSX, $45 kit) 

- JetFind: super fast, extemely flexible text file scanner ($50) 

• ZMATE: macro text editor / customizable wordprocessor ($50) 

• PCED — the closest thing to ARUNZ and LSH (and more) for MS-DOS ($50) 

• BDS C — including special Z-System version ($90) 

• Turbo Pascal — with new loose-leaf manual ($60) 

• SLR Systems (The Ultimate Assembly Language Tools) 

- Z80 assemblers using Zilog (Z80ASM), Hitachi (SLR180), or Intel (SLRMAC) 
mnemonics 

- linker: SLRNK 

~ TPA-based ($50 each) or virtual-memory (special: $160 each) 

• ZMAC — Al Hawley's Z-System macro assembler with linker and librarian 
($50 disk, $70 with printed manual) 

• NightOwl (advanced telecommunications, CP/M and MS-DOS versions) 

- MEX-Plus: automated modem operation with scripts ($60) 

- MEX-Pack: remote operation, terminal emulation ($100) 

Next-day shipping of most products with modem download and support available. Order 
by phone, mail, or modem. Shipping and handling $3 per order (USA). Check, VISA, or 
MasterCard. Specify exact disk format. 

Sage Microsystems East 

1435 Centre St., Newton Centre, MA 02159-2469 
Voice: 617-965-3552 (9:00am - 11:30pm) 
• Modem: 617-965-7259 (pw=DDT) (MABOS on PC-Pursuit) 



